[next] Backports and Release

[raimund-schluessler]

@nextcloud-libraries/developers The vue3 next branch needs some love. There hasn't been a release since Jul 16, corresponding to nextcloud/[email protected] (we are at nextcloud/[email protected] already). This leads to a lot of missing features and fixes in next, which makes e.g. the Tasks app (to my knowledge still the only app using vue3 in production, unfortunately) not working perfectly with NC30.

Also, the backports from master to next are neglected badly.

In my opinion, this should be the next steps here:

• Do a nextcloud/[email protected] immediately, to have available what has been backported at least.
• Backport every missing PR from master to next. Although that will be very many, it might be easier even to "just" merge master into next (although this will require a lot of manual work, either way).
• New release of nextcloud/[email protected].
• Make next the new default branch (name it main in light of new standard, and to reduce confusion) to force people to develop for vue3 and get it backported to stable8 (new name for master) if they need fixes (or features, which they shouldn't, honestly) for vue2.

[raimund-schluessler]

Personal side-note:

I understand that migrating such a huge project as Nextcloud from vue2 to vue3 is a pain, takes a lot of effort and is barely visible to users (i.e. cannot be sold as "we added a great new feature"). However, it was long clear that vue2 will reach EOL at the end of 2023 and even 9 months later Nextcloud still uses it and does not really take care of vue 3 (not even backporting, let alone making it the default target). While vue 2 hasn't had any major vulnerabilites (citing from Vue 2 EOL), I think it is a really bad practice to use unmaintained libraries, especially for a project like Nextcloud, that advocates for "keep your software up-to-date" with every own release.
Furthermore, there has been a lot of community effort to push the vue 3 migration forward, nextcloud/vue has been completely migrated, and next and master were on feature parity, but it was not picked up by the company, unfortunately.

[susnux]

Do a nextcloud/[email protected]

Sure, just prepare the PR :)

Backport every missing PR from master to next. Although that will be very many, it might be easier even to "just" merge master into next (although this will require a lot of manual work, either way).

I think everything that is needed is backported. A merge I think will no longer work, both branches are to diverged already.

---

In general after talking to many people at the Nextcloud Conf. / Contributors week (this week), the overall opinion seems to be:

1. Ensure both v8 and v9 provide proper model values

• for v8 add update:modelValue besides all input events and deprecate input where needed
• for v8 add modelValue prop as duplicate of any prop that is considered the model value (often just value but there are also some places where a different name is used)
• backport both to v9
• remove the deprecated ones from v9

2. Release a beta version (at this point we shall switch default branch)
3. Release new versions of all component libraries (upload / dialogs / ...) built on top of the beta version
4. Migrate some example app (e.g. Notifications or Activity) so people can take that as an example for their apps
5. Start migrating Nextcloud apps
6. Migrate Nextcloud core (this will very likely not happen for 31, but currently discussed for 32 after we have experience with how the app migrations worked out).

But overall Nextcloud employees will probably not have much time until 30.0.1 release - so I expect 1 and 2 not before that time.
This is what I think was the consent of the discussions I had about that topic this week / at the conference.

[dartcafe]

I would like to second this and want to additionally point the interest to #5950 which is the last issue which keeps me from releasing Polls on pinia and vue3 to the beta state.

[dartcafe]

And the cherry on the cream would be a vue3 compatible version of @nextcloud/dialogs

[raimund-schluessler]

What would be the benefit of this approach outlined below?

1. Ensure both v8 and v9 provide proper model values

• for v8 add update:modelValue besides all input events and deprecate input where needed

• for v8 add modelValue prop as duplicate of any prop that is considered the model value (often just value but there are also some places where a different name is used)

• backport both to v9

• remove the deprecated ones from v9

I think this just brings further effort for developing v9. v9 already uses modelValue everywhere (given we did not forget a place). Bringing modelValue additionally to v8 would of course allow app devs to switch to modelValue with v8 already. But the amount of work would be the same, and the move to v9 would still be a breaking change. So why make it more complicated than it is? Just move your app to modelValue when you migrate to v9.

[susnux]

Bringing modelValue additionally to v8 would of course allow app devs to switch to modelValue with v8 already. But the amount of work would be the same, and the move to v9 would still be a breaking change. So why make it more complicated than it is? Just move your app to modelValue when you migrate to v9.

The idea is to make co-maintaining v8 next to v9 (in apps) easier. If you use non-deprecated v8 props / events / functions you should ideally have only to switch the version number in the package.json.
Because the vue3 specific changes are not really a problem on API level, there are some exceptions of course, but in general it should be possible to just keep everything working.

E.g. take NcInputField, there is no reason why you should have to change anything between v9 and v8.

---

I would like to second this and want to additionally point the interest to #5950 which is the last issue which keeps me from releasing Polls on pinia and vue3 to the beta state.

Pinia works fine with Vue2 and Vue3 and also Vuex works with Vue3 and Vue2, meaning you could also just release Vue2 + pinia first or keep Vuex with Vue3 (while I do not recommend as Pinia replaces Vuex).

That issue is sadly a bit of technical dept we also discussed, we did the mistake in the past to wrap external libraries without proper abstraction. This means we can not simply switch the underlying library without making it breaking (proper way would be provide own abstractions of what is really needed and not pass everything down).

But I agree this is something to be fixed, while I also strongly recommend to use the native variant where possible.

[dartcafe]

Pinia works fine with Vue2 and Vue3 and also Vuex works with Vue3 and Vue2

I can confirm that, stating from the point an app migration. I went through the migration by first replacing vuex by pinia before i went through the complete migration (vue3 and ts). It was a good way to get familiar with the composition API and TS.

That issue is sadly a bit of technical dept we also discussed, we did the mistake in the past to wrap external libraries without proper abstraction.
[...] But I agree this is something to be fixed, while I also strongly recommend to use the native variant where possible.

Switching to the native picker would mean a heavy pain, since I tweaked the picker to the behavior, it has now. From what I observed, it seems 'just' to be an issue of the thrown events, but I am not familiar with the code of the nextcloud implementation. It works as before, but the dialog is just closed unintentionally on every click.

But good to read it is on the table.

My pain is just, I have a completely migrated app, ready for beta status. But it can't be released, because this issue causes a huge UX impact.

[nursoda]

I second that the migration to Vue v3 should be prioritized. This issue dates back to September, 30.0.1 was released 2024-10-18, there's a forum question on v3 plans from 2024-03-04, v2 is EOL since 2023-12-31 and its EOL was announced 2022-07-01. But still we see nothing here.

Requiring Vue v2 prohibits current versions for other components. This is dependency hell in terms of security. I am aware that many of them are dev deps. Still, for a platform that challenges the big players, a solid base is a must. As maintainer of an app that is supposed to increase security, I NEED to get rid of rogue dependencies.

Personally, I have minimal GUI and don't care about the migration effort. But there should be some howto covering typical migration steps, a Vue v3 app skeleton and ideally an updated tutorial. Until then, I'll try to grasp the concept from Polls and News – thanks for pioneering, guys.

[nickvergessen]

Just copying over from chat:

---

@dartcafe

Hello together.

I would like to raise a discussion about the state of the vue support. IMHO we need a plan for the update to vue3, since the count of known security issues raise for the vue2 based branches.

I see a lot of design updates for the vue components, but little to zero effort for the vue3 branch. Is that critical to fix design issues for a dying version?

It is not getting easier for developers of current apps and if someone wants to start a new app, he has to start with vue2 because most of the dependencies of the nextcloud ecosystem are still basing on vue2 or still in alpha state.

I have the feeling, that the big trouble will come soon and nextcloud may become insecure. Not a good thing for the reputation.

In Polls there are alone 20 security issues for the main branch, partially caused by a vulnerable vue version.

---

Someone:
You can already update to Vue 3 :)
Some apps at Nextcloud already did
But yes, we should pace up

---

@ShGKme

I think, @dartcafe meant that we should be vue3-first (he already supports Vue 3 app).

For example:

• Have nextcloud/vue v9 as main and backport to vue 2 branch instead of forward port to next
• Have all Vue-related libraries released and actual for vue 3

---

Someone:
👍 from me!
(with 3 up votes)

---

@ShGKme direct response:

👍 from me!

Would you like to make vue3-compatible main branch/version of @nextcloud/upload? 👀

---

@dartcafe

Sure. I can upgrade to vue3 and I did.

But:

• nextcloud/vue is still in alpha state and has unresolved bugs
• nextcloud/dialogs is still unpublished and only usable from the #vue3 branch
• nextcloud/l10n throws vulnerable (high severity)
• nextcloud/files is vulnerable (high severity)
• nextcloud/moment is vulnerable (high severity)
• nextcloud/vite-config is vulnerable (moderate severity)

And if I understood the dependencies, it is at least all based on vue2 which is vulnerable up to version 2.7.16 (the final vue 2 release).

Additionally unresolved bugs in nextcloud/vue are preventing a productive release with vue3.

Don't get me wrong guys, I appreciate your work, efforts and the idea behind all of it. But I would love some more support for maintainers and developers of independent nextclouds apps. At least by maintaining the ecosystem to an up to date state.

@ShGKme Yes. This what I mean. We have to get out of this situation. There are still many apps which have to be migrated to vue3 and I bet most of the developers would like to start, but did not until we have a stable situation.

I for myself maintain two branches of Polls in my free time, one for vue3 (meanwhile with the great help from (sorry Come, not Barth) some other nextcloud contributors out of know reasons). And a vue3 branch which is in alpha state since months, because it is not possible to even release a beta version out of the prior mentioned reasons.

And yes, the nextcloud/vue 9.x version together with vue3 compatible libraries of the nextcloud-libraries should be prioritized over the 8.x version. Every enhancement should go to the vue3 branch to provide incentives for a migration.

Thanks for listening! :-)

---

@ShGKme

And yes, the nextcloud/vue 9.x version together with vue3 compatible libraries of the nextcloud-libraries should be prioritized over the 8.x version. Every enhancement should go to the vue3 branch to provide incentives for a migration.

I agree, and I think we should do it in Jan 2025, or after the Nextcloud release

---

@raimund-schluessler

I would very much love to see the topic discussed above being resolved. This is basically what #6106 is about.
And I have to admit, it would probably increase my motivation to contribute to NC a lot!