Sticky stable update channel

[MorrisJobke]

We just had a request by @tessus (nextcloud/updater#159) to provide the admin a channel that allows to stay on the installed major release.

I guess that makes sense to provide. It would then only switch to the next major release at the EOL of that release. It would also allow people to stay on a version if they know that the next major release still has a bug, that they experience but still want to have a maintenance release.

Basically then something like old-stable (ideas for names are welcome) which provides as of now following releases:

• on a 10.0.x instance: 11.0.7 (because 10 is EoL)
• on a 11.0.x instance: 11.0.7
• on a 12.0.x instance: 12.0.5
• on a 13.0.x instance: 13.0.0

@nickvergessen @jospoortvliet @rullzer Opinions about this?

[rullzer]

Yes makes sense. As we want as many people as possible to use the updater adding a channel like this seems like a logical step.

[tessus]

Thank you for taking this into consideration.

As for naming suggestions: how about locked-release, since the channel is locked to the currently installed release.

[nickvergessen]

maybe that can finally be the difference between stable and production 💃

[MorrisJobke]

maybe that can finally be the difference between stable and production 💃

That would not make sense ... production should be updated more early IMO. (with .2 or .3 like we do it right now - only messed up during the 11 -> 12 transition).

[Nils160988]

For me as a user, the difference between stable and production has always been somewhat unclear, so I would support @nickvergessen
So, the chanels would become more similar to the way of debian/ubuntu. You can either choose the stable/beta branch or you can use the codename of a specific branch.

[rullzer]

Maybe we just do this kind of like how docker allows you to do tags?

So there are stable tags:

• stable11 => latest stable version of 11
• stable12 => latest stable version of 12
• stable13, stable => latest stable version of 13

We can then do the same for the beta channel.
When we have the EOL flag in the updater we can anyways signal people they are running a version that is EOL.

We could even do the same for production channels if needed?

This has the advantage the behavior is explicit. And admins probably quickly understand it.

[MorrisJobke]

I would avoid to create a ton of new channels. The idea of this is to have one additional channel and not an overcomplex tagging system. This additional channel has then the characteristic to keep you on the same version (until EoL) - nothing more and nothing less.

[rullzer]

ok fair enough. Lets just do that then. And think about more complex stuff is a need arises.

[MorrisJobke]

Once we have this it should also be added to the description section of the channels: #8815

[tessus]

@MorrisJobke any update on this?

[jospoortvliet]

@tessus it won't be for 14, but might be done for 15 if somebody wants to do the work.

[tessus]

@jospoortvliet if somebody would have pointed me in the right direction I could have looked into it.
I do not even know where to look in the code to find this.

yet, 5 months later, somebody decides that this is too much work. don't get me wrong, but this shouldn't take more than a few minutes for somebody who knows the code.

[jospoortvliet]

@tessus sorry you're frustrated that nobody jumps on this task, but it simply depends on somebody who wants to put his free time into this. There are hundreds more tasks that take 'just a few minutes' and they're all very nice and useful to somebody. If a volunteer wants to do this, that is of course great.

And if you wonder "but don't you get paid to work on Nextcloud", then, well, yes, but we get paid by customers and they didn't ask us to do this.

[tessus]

sorry you're frustrated that nobody jumps on this task,

No, I'm frustrated, because nobody thought of mentioning this earlier, as in 5 months ago. Now people still have to update manually, because somebody thought it makes sense to force people to migrate to a newer version.

And if you wonder "but don't you get paid to work on Nextcloud", then, well, yes, but we get paid by customers and they didn't ask us to do this.

Actually no, but I wonder about something else. So what's different to owncloud then? (Better developer / community relationship? Hmm, I think you just proved the opposite.)
Others would call this attitude use and abuse the community. Anyway, I've mentioned several times before that the priorities are off in this project. Now I know why. You want to make money by developing new features instead of fixing bugs and bad design decisions. Now everything makes sense. Thank you for clearing this up for me.

[bpcurse]

Basically then something like old-stable (ideas for names are welcome)

In line of the existing names:

daily
beta
stable
production

name proposals:

• lock-major
• keep-major
• production - locked
• production - minor updates only
• production - ignore major updates
• production - keep version
• production - locked major
• production - hold

[MorrisJobke]

I just had a few more thoughts about this topic and I think there is an even better way without increasing complexity here.

What if we use the production channel with some adjusted behavior for this. Then the production channel only will serve the major version upgrade once the instance is on the very latest minor version. In this way you can upgrade minor versions even if stable gives you the next major one and we don't need to introduce another channel for this. Still you always have a reminder that there is a new major version available and you can properly schedule when to do it. That means

• production will serve the major upgrade a bit later (around the .2 release) and only when the instance has the latest minor version installed. examples: 14.0.5 -> 14.0.7 and 14.0.7 -> 15.0.4.
• stable will keep like it is now - proposes major upgrades even of not on latest major version - this reduces the number of needed upgrades. examples: 14.0.5 -> 15.0.4.
• beta will keep like it is now

That solves following requests:

• I'm on an old minor version and only want to upgrade to the latest minor on that series
• I want to be able to schedule when to do major upgrades, but don't want to suffer from old minor versions
• The admins are still informed about new major versions and know that a schedule for this upgrade should be made
• Instances don't need to wait until the EOL of a version to get notified about a new major version and thus updates to the next major version are not too delayed

Does that sound good?

cc @blizzz @rullzer @nickvergessen @ChristophWurst @danielkesselberg @rakekniven @tflidd

[MorrisJobke]

The text in the updater page is adjusted in #14168 and the behavior is changed in nextcloud-releases/updater_server#189

[tessus]

@MorrisJobke Thank you. This change is great. The only issue I can see is that people will always receive an update notification.

Let me explain: Someone is on 14.0.7 and the updater shows that 15.0.4 is available. When 14.0.8 becomes available, the updater will show 14.0.8 instead.
So no matter what, the updater will always show an available update.

This is not really a problem, but as an admin I'd rather get notifications only for updates within my major version. In any case, I'm very grateful for this change. Now I can use the updater for applying patches within my major. Thank you! 👍

[MorrisJobke]

The only issue I can see is that people will always receive an update notification.

Actually that is the feature we definitely want users to experience. We want people that are aware that there is a followup version and that upgrading is the way they should go.

Thanks for this feedback 👍

[tessus]

Actually that is the feature we definitely want users to experience.

Ok, got it. It's just that a dismissal of the notification does not mean I never receive it again. After a while it pops up again :-( Anyway, I can always turn notifications off...

In any case, I'm really happy about this change. Thanks again.