Server: Consider periodic LTS releases (at least security updates?)

[timlepes]

The relatively rapid release cadence puts older versions out of support too quickly for those who don't want to upgrade so fast. Some want stability more than new features, or want to test new versions for a while. Or maybe generally don't like to fix what isn't broken. But security updates, in particular, matter. It would be a lot to ask or expect you to support very many versions prior. But perhaps one older "LTS" version can receive some love for a longer period than 12-18 months or so?

According to "https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule", version 11 got about 15 months, version 12 got 18 months, and versions since seem to be getting 12 months each. Maybe you could land a solid release and give it 3 or 5 years of security fixes? Its that reasonable? I understand you offer paid support. But this would give people who want to "stay behind" the update cadence something secure they could stick to, rather than running versions that receive no updates, security or otherwise. I know you guys care about these things, and so it would be a public good if you could pull it off. Thanks.

[MorrisJobke]

In general: we offer special long term support for customers of Nextcloud GmbH, where we together with the customer have a look at the big picture, which involves the underlying operating system as well as the used PHP versions for example. This is critical here, because it would be useless if we support and fix a version of Nextcloud, but it only runs on a totally insecure runtime.

For example the Nextcloud 14 release runs with PHP 7.0, 7.1 and 7.2. Some things were updated with PHP 7.3 that made the Nextcloud 14 release not compatible with this runtime and we fixed that for Nextcloud 15. 7.0 is already EOL, 7.1 will it in 10 months already. Have a look at the schedule in https://secure.php.net/supported-versions.php.

Then the next thing we are currently working on is the option to upgrade from any version to the next one. Currently this is not enabled. From a technical point of view we prepared this and use since some version migrations within the server code itself. Not all apps are migrate there to also support migrations and not use the old way of having the existing DB structure, compare it to the wanted one that is described in the app code and then doing a diff of the needed SQL statements.

Furthermore it makes also upgrade scenarios quite more complex as the matrix of where instances are upgraded from are raised a lot.

Regarding the "no features, but we want fixes": we actually provide this at least for 1 year as you have already written. Unfortunately sometimes a fix of a bug or security issue comes with a fundamental change of how things work and it gets harder and harder where to draw the line of a "this is a fix and we should backport", "this is a fix, but it breaks compatibility with existing clients out there" and "this is a fix, but it makes the product work in a completely different fashion". Which of them are fine to backport and which not?

Beside that our major version aim to not break existing setups usually (except from Nextcloud apps, that need to be updated, because they use code that was deprecated years ago and didn't received a proper code update - but this is a whole different story we are also working quite hard on). The upgrades we provide often work totally fine with existing mobile and desktop apps that are installed at end users. So there is rarely any interruption on that side. Also the administrative side should be covered quite good and a minor and major upgrade can rarely be identified from an upgrade experience (in matter of duration, downtime, problems, handholding, ...) in general. Sure - sometimes it's not as smooth (especially the first version of a major release has some rough corners with super specific configurations, but we do our best to iron them out far in advance). That is what we want to give to the community as the production channel - a way to stay up to date and once the major version is solid enough to get a no-brainer upgrade we put it live in there. (usually around the .2 or .3 release of a version).

To sum this up a bit: we want to make a robust product that has the option to evolve and brings stuff that helps people to do their job (dealing with files and collaborating) far easier. And an LTS version rarely makes this easier as it is not an end user software that needs to be upgraded on potentially thousands or tens of thousands of devices but on a server. it seems to make the life of admins easier but it fact continuous small upgrades aren't that bad if they run just fine compared to this one big upgrade that may break apart once every 3 years. Also then the round trip time for fixes is quite high, as the product itself moved forward an enormous amount of code/behavior/ccompatibility/etc. We want you - the users and admins - to be in the loop. Give us feedback what we can make better to improve your live. Also the administrators experience is something we want to focus on - see the setup checks for example where we try to detect issues, that you either need to find yourself from metrics or misbehavior, upfront and link to potential documentation pages. ;)

And just another behind the scenes story: there are customers at the company that are quite big and where our thoughts were more in the direction of "We think that they want to stay on an old version very long to avoid upgrades because it's a huge instance and they want as few moving parts as possible" that are now actually the ones that upgrade first. This is due to the fact that upgrades are usually without issues (and we as company provide standby support with subscriptions, which gives them the confidence that if something happens someone is there) and second they want to be in the loop where the project heads to. They give important feedback to how Nextcloud looks and works which then is incorporated. Also they are happy with that decision as this makes our all lives easier and we can focus on bringing a solution to the end users - which is the overall goal for this whole journey here, right?

Long story short:

• we also thought and discussed this topic quite often
• there is no way around minor upgrades (due to security requirements in web platforms) and major upgrades should be as easy and stress free as minor ones
• we are not unconvincable - but the demand-cost-advantage-effort ratio is quite bad as of now
• staying in the loop is essential from our perspective

I hope that makes at least some sense and answers the questions you raised.

cc @karlitschek @nickvergessen @rullzer @schiessle @ChristophWurst @jospoortvliet

[timlepes]

Thank you so much for your well considered reply! I am impressed that you spent as much time as you did and cared to be thorough in your reply. So again thank you, Morris. I am satisfied with your reply. I hadn't considered the underlying dependencies like PHP versions being an issue... I am a long-time IT person but not a developer, so I can only best-guess at the issues you would face. I truly appreciate being able to engage with you (the developers) and getting such prompt feedback. I'm going to pass your answer on to the Youtube comment thread (on a NCv15 review) that inspired me to report the feature request. I will close this issue as it is apparent from your answer that you (the dev community) are well aware and mindful of the issue.

[MorrisJobke]

@timlepes Thanks for the nice words 👍