So if itās a bugfix release, why is the major version number being incremented?
Just to break compatibility with 3rd party apps for no good reason?
Someone at Nextcloud needs to learn semantic versioning (https://semver.org). Users would be much better served by an 18.1 release than a 19.0 release with no significant user visible differences. Even from a purely marketing perspective, it sends a clearer signal.
Please stop incrementing major version numbers unless thereās a significant reason to do so, like a major new feature, or a change that breaks compatibility for apps.
We donāt know that. New features could be in some apps, or even completely new apps that are not public yet. You can just guess from what you see in the new version and what is on github. And even then, there could be some hidden things, that break compatibility that would justify a new version number.
At this breakneck pace - four major releases 16-17-18-19 in a year and a month - they donāt have enough time to even list all the betas released (there was a Beta 7!) forget about its detailsā¦
I know we donāt know that, I was responding to @Paradox551ās statement.
But even if all the new features are just in apps, that doesnāt justify a major version change.
And frankly Nextcloudās lack of communication about features and potential breaking changes in new releases is a problem in and of itself. If app authors really need to update their apps for compatibility, wouldnāt users be better served if the authors had the information they needed to update their apps before the Nextcloud release? The silence helps no one.
Every time thereās a major version change, thereās a whole raft of apps that stop working, even though the majority only need their compatibility information updated. This just creates unnecessary havoc.
A sensible versioning system, that actually advertises compatibility for apps would allow most apps to just keep working. e.g. SemVer
Donāt get me wrong, I appreciate the rapid addition of features and release cadence, it just needs to be done in a way that isnāt so disruptive to users and 3rd party developers.
Not speaking about the apps. The nextcloud/server repository is more or less bug fixes and improvements.
But even with the apps on RC2 I donāt see many differences. Your mileage may very.
Regarding apps: None of the major ones have stopped working. Passman, passwords, contacts, calendar, audio, collabora - no issues. I donāt know or care about the less known ones.
Last I checked carnet, metadata, raw, checksum - they worked as well.
If you know any apps with compatibility issues then report them. 19 is not released yet!
Iām not testing the Gallery app because itās not supported and I donāt use it. Youāre welcome to install it though! The beta is open for everyone.
The error you listed for social is likely the MySQL bug here. I use postgresql so it would likely work correctly for me anyway.
Donāt use preview generator but video thumbnails are generating correctly for me.
Not speaking about the apps. The nextcloud/server repository is more or less bug fixes and improvements.
Right, which doesnāt give justification for a major version number change for the Nextcloud server. If the apps change, change the version number of the apps.
Regarding apps: None of the major ones have stopped working
My Nextcloud currently reports the following apps as missing updates for V19:
Activities for shared file downloads, visible to all admins
Full text search
Full text search - Elasticsearch Platform
ONLYOFFICE
Quota warning
Ransomware recovery
Thatās a significant list. An upgrade now would have a major impact for me, so I will not be helping test V19. Now, if thereās really nothing other than bugfixes in the core server, I expect all of these apps to work just fine. However, since those apps donāt claim to work with V19, theyāre all going to get disabled in an update, or prevent me from wanting to update in the first place. How is that helping anyone?
If the release were marked as V18.1, (and Nextcloud actually followed the semantic versioning contract) then Iād expect most (or all) of those apps to claim to still be compatible without the app author having to issue a new release just to bump the version number.
Yes, I know it hasnāt released yet, but this situation happens every time thereās a major version change and there are always a significant number of apps that havenāt updated their compatibility info when the release actually happens, sometimes taking months to update because the developers have other jobs. Often many of them require no changes other than the compatibility info. This puts a completely unnecessary burden on app developers and users alike. Iām asking Nextcloud to re-think their versioning system.
Thatās my point. I shouldnāt have to test each app individually to see if maybe they work after all. They shouldnāt be reported as incompatible in the first place unless thereās a good reason to believe they might be. Bug fixes is not a good reason.
Simply bumping the major version number triggers a whole bunch of false positives on that list that serves no purpose and causes harm to app developers and users alike. It also harms Nextcloud by discouraging people from testing new releases.
Let me phrase that another way. Bumping the major version of the server forces every app onto the incompatible list, until the app developer releases a new version that increments the known compatible version.
Why should app developers have to do that for bug fixes in core?
I guess apps without a compatible release are marked as incompatible Afaik the process is that app developers are asked to increase the max-version, check if the app still works (for some apps the ci is doing this) and upload a new release.
As you already mentioned the semantic versioning / release strategies discussion is off topic and the right place for such a discussion would be GitHub anyway.
Thanks. Yes, sure. I do have a test instance that I can do such experiments on. My post was meant as a status on which app devs did the compatibility check.
Nextcloud team cannot and shall not test all apps and the whole idea of apps in the context of major upgrades is that the core system is released and then app devs ideally follow-up and release compatible versions.
There are some apps though that are marked āofficialā ā at least these should be compatible prior to the release (read ānow, itās RC2ā).
And for many of us, different 3rd party apps do matter much since NC is used as a base for an application (such as a photo gallery, or a groupware server). So the status of which apps are marked ācompatibleā by their devs does matter.
This does not and shall not mean that nextcloud ācoreā/āhubā itself should not be released once itās ready, independent of the app readiness. Itās the adminās job to check if ALL parts of the application are ready to migrate the core system.
[Please allow me one more sentence on semantic versioning: I agree that it would be a great relief for app devs since there seems no need to migrate an app from 18 to 19. In my opinion, the compatibility check / adaption for PHP 7.4 was worth a major version (17ā18). So yes, please, open an issue someone if @kesselb thinks thatās the right place. Personally, I donāt think so. Itās a marketing decision of Nextcloud, not a bug, and it should rather be discussed on a conference.]
I agree that āofficialā apps should be ready by the time a release is RC2.
But then again, considering the history of OnlyOffice ārockyā relationship, I wouldnāt be surprised if Nextcloud just wants to forget about itā¦
Consider it a MS Windows release: worth looking into (for production use) after service pack 1ā¦