Vue3 version: Release schedule

[raimund-schluessler]

Release schedule for Nextcloud Vue with Vue 3 support

We will release a stable Vue 3 version soon, to do so the plan looks like this:

1. ✅ We will close the breaking changes windows with the first RC.
2. Based on this RC we will create Vue 3 versions of all Vue libraries
   • @nextcloud/dialogs
   • @nextcloud/password-confirmation
   • @nextcloud/upload
3. We will check for issues and flaws, breaking changes can still happen if really needed but should not.
4. Once those libraries are available we will migrate one or some smaller apps to Vue 3. With this practical experience we can check if everything works as expected.
5. We finalize a v9.0.0
6. We migrate Nextcloud apps.

Time schedule

• First RC:
  • Planned between 2025-04-07 and 2025-04-11 2025-04-25
• RC release of Vue 3 based libraries
  • Planned as soon as the RC is released, probably between 2025-04-07 and 2025-04-18
• Final release:
  • April 2025
  • 2025-09-04 together with the first RC of Nextcloud 32

Original issue

@nextcloud-libraries/developers The vue3 next branch needs some love. There hasn't been a release since Jul 16, corresponding to nextcloud/vue@8.14.0 (we are at nextcloud/vue@8.19.0 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/vue@9.0.0-alpha.6 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/vue@9.0.0-alpha.7.
• 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/vue@9.0.0-alpha.6

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.