No, only saing that a good LTS policy is also part of good software. I would prefer paying for fontionalities rather than only old good software.
That’s called the enterprise channel
A home user license that provides access to LTS versions would certainly something they could offer. However, for reasons I don’t know, they decided against it.
On the other hand, I don’t think the situation is as bad as you and others make it out to be. As I said, with a more conservative update strategy you can actually get along pretty well. Of course, just clicking on an update button every two years and not worrying about anything else is not possible with Nextcloud (as with hardly any user facing software nowadays), and probably never will be.
Btw, if you only using the “Featured” apps, and if you are not an app developer, you will have little to no issues with API changes anyways, because the core apps are usually ready when a new version major version of NC is released. Of course you still have to to do one or two major upgrades a year, but you won’t likely run into any major issues.
Yes they offer LTS, and even for free. Bu they also have commercial offerings of their software with additional features like e.g. cluster and HA functionality: Production-Grade Open Source Database: MariaDB Enterprise | MariaDB
I have discussions on just this for small business. I have several that really need some kind of small business license.
Yeah, there seems to be a gap for SMBs with less than a 100 users, however €36/user/year seems reasonable to me. Nextcloud Enterprise pricing
On the other hand, you still need to maintain your instance, even with an Enterprise subscription, and therefore you still have to pay someone to to it. Or you can of course maintain it yourself, and pay with your time.
So either way, as a small company, there must be a large portion of idealism involved in order to justify hosting your main office platform yourself, because, if you want to do it right, it will probably always be more expensive (either in time or in money, most likely both) compared to something like M365 or Google Workspace.
Let me be clear: i’m not talking about a LTS with normal backports, but, at least, with Security backports. For example, the v24 is now EOL. It passed from Active to EOL.
PHP has 3 phases : Active, Security, EOL.
This could be a good approach.
Not sure what you mean or where NC is fundamentally different to PHP, except for the fact that PHPs release cycles are longer. However, it doesn’t really matter, because I’m pretty sure, they won’t change anything, at least not anytime soon. And even if they should change their minds, and start selling subscriptions to end users or small businesses, they would most likely continue with their existing release cycles for the Community and Enterprise editions…
So I’m afraid if you want to to see fundamental changes regarding their development process and release strategy, at least in the foreseeable future, you’ll have to fork Nextcloud. Personally, I would certainly check out Bloocloud LTS once it is released, not sure if I would use it on my main server, though.
For such topic, it might be worth discussing this during the Nextcloud conferences, where community member are welcome as well and you can exchange with core developers and third-party app-developers and others. Not everybody can go there, but perhaps we can gather and vote for a few questions that we can ask and report back to the community.
In the early days, they chose the current model to be able to quickly improve the software. Perhaps this is or will be different, and it might be worth investing resources for that. Unfortunately, they are a company as well, and if this more flexible release support were a major source for income, it would be less likely.
I don’t have an issue with the release cycle. It’s about tying API changes to the releases. Again, think “web operating system”, not “monolithic app”.
Take M$ Windows or macOS or even Linux: no matter how often I update any of these, my apps keep working. Why? Because despite all internal improvements and bug fixes, the API remains stable.
Except for low level apps, like real-time audio, things “just work”
So, what I’m advocating moving to, now that Nextcloud clearly has matured to a significant degree, is keeping app and API versions separate.
API versions should be major.minor, where minor versions only ADD features without breaking any of the existing functionality. e.g. every app designed for API M.m is able to run on any version of Nextcloud with API version M.(m+x) (x being a positive natural number, of course )
Whenever an API version breaks backwards compatibility, that’s when a new major number should be introduced.
That should not need to be the case more often than every 3-5 years, one should think,
Consequently, apps in the store could be designated a API version which they require, like e.g. 5.2 meaning they will not run with any API version lower than that, but will run with any API version 5.x (x >= 2) and will need to be requalified for API version 6.x
As a result, users, for the entire duration of the API 5 upgrade cycle, don’t have to worry about that app anymore. But that doesn’t mean that Nextcloud needs to be static in that time. API additions are possible at any time, and so are other bug fixes and feature upgrades. Meaning, if API version 5 should hold, NC could go from 26 to 37 while API goes from 5.0 to 5.9 and no apps designed for the 5.0 base would be unaffected by any of the changes.
I’m not doing external app development and I’m only a minor recent (outside) contributor to the core and various peripheral bits, but my take is that the major version number of NC is the API version.
In effect app releases in the app store are already tied to a particular API, which is exactly why there are multiple releases for any given listed at a given point in time. How this is managed at an app level varies - some apps manage to maintain the same version across NC versions while others have different major versions or release variations (e.g. contrast Deck’s releases versus Notes’ releases). I imagine this is a byproduct of a mixture of what NC API dependencies a given app has and individual choices made by app developers to maintain compatibility. Also, where the app version isn’t compatible with multiple NC versions, it’s the app developers prerogative whether to backport functionality to builds for older NC versions or not (where it’s an option I mean).
If you haven’t already, you may want to monitor the API/notables docs collected for each major release that is targeted at internal core+app developers as well as external app developers.
For example, here is the v26 set:
For apps versioning and release management, there is the NC suggested approach (particularly the Shipped Apps - Versioning section) which seems relevant to mention here as well:
In effect app releases in the app store are already tied to a particular API
Which are always tied to a Nextcloud server release, which is what is being discussed.
In my opinion what is being suggested is very reasonable: to untie the API version from the Nextcloud feature releases. This would alleviate the pressure for app developers to need to test their apps every few months. While not changing the maintenance schedule for the Nextcloud server.
Speaking as an app developer, I know I should be testing my app against Nextcloud 27 beta already, but I lack the motivation to do so. Partially because I feel like I just spent this effort for Nextcloud 26 not even 2 months ago.
Makes total sense. Honestly, this is it’s own discussion topic. Nextcloud 27 is set to be released in the next two weeks… perhaps there could be a way to manage app release compatibility untied from the API. Great idea!
Yes but no. Nextcloud server doesn’t always have removed/breaking APIs. The major releases are done by schedule, not by type of change. Deprecated APIs are also not removed in the next major but three major releases in the future at the earliest.
So for app devs it is relatively easy to upgrade.
Enterprise grade is simply not available for home users with a small number of users. There is no choice.