We are still in a fast development cycle, so the versioning is to keep track of the progress/iteration of the project. When a stable release is reached (2?), then any breaking change would require more proper major version changes
Yes, I understand they have declared that. Their declaration does not, however, negate the common semantic versioning standards, found at semver.org. These common standards are significant for admins running shared systems where they automatic upgrade processes based on common semantic versioning rules. The software will stabilize and they will adopt a more stringent policy. But they should still be releasing 0.x versions since they’ve not yet reached it.
Tbf this is actually version v1.136 .0 and
Disclaimer
Personally I’m waiting for the day it comes out of “under active development” state so that I can migrate from NextCloud to it.
A breaking change should have been 2.0, not a new 1.<minor> release.
It should still be 0.<minor> if they’ve not reached the stability for keeping backwards compatibly in all 1.x releases.
To quote them:
Yes, I understand they have declared that. Their declaration does not, however, negate the common semantic versioning standards, found at semver.org. These common standards are significant for admins running shared systems where they automatic upgrade processes based on common semantic versioning rules. The software will stabilize and they will adopt a more stringent policy. But they should still be releasing 0.x versions since they’ve not yet reached it.