Immich isn’t a library (the main use case for semver is dependencies that will be pulled into other projects) and as far as I know they don’t state that they use semver.
It only affects undocumented behavior, no documented behavior is being broken.
If you want to consider breakage of undocumented / unintended behavior as a major change, then every bug you fix would require a major version bump, since when you fix something you are essentially breaking compatibility for anyone who might have possibly relied on the existence of that unintended behavior.
I was going to say you are wrong about semver but you are correct that it should simply not be version 1 yet.
To quote semver.org:
“Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.”
If they had just done that, their disclaimer would be implied. Once it is 1.0, breaking changes require a major version change. That seems like reasonable policy to me.
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.
I’ve been meaning to give this a try on my Synology.
But breaking changes in a point release? Not cool.
From the release notes:
So you’ll probably want to wait until they do a stable release.
Yes indeed. 🙂
It’s a full release, not a point/patch release, the title just doesn’t show the second .0. They use semantic versioning so it’s major.minor.patch.
It’s also a very minor change and only affects a single configuration property and only people who used relative paths in that property.
Breaking changes should warrant a 2.0 version, not a 1.minor version.
Edit: I am basing my comments on https://semver.org/ guidelines
Immich isn’t a library (the main use case for semver is dependencies that will be pulled into other projects) and as far as I know they don’t state that they use semver.
But it is a service that clients connect to via an API.
The API specification is unaffected by this.
It only affects undocumented behavior, no documented behavior is being broken.
If you want to consider breakage of undocumented / unintended behavior as a major change, then every bug you fix would require a major version bump, since when you fix something you are essentially breaking compatibility for anyone who might have possibly relied on the existence of that unintended behavior.
Tbf this is actually version v1.136 .0 and
Disclaimer
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.
I was going to say you are wrong about semver but you are correct that it should simply not be version 1 yet.
To quote semver.org: “Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.”
If they had just done that, their disclaimer would be implied. Once it is 1.0, breaking changes require a major version change. That seems like reasonable policy to me.
That said, I upgraded without issue.
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.
Personally I’m waiting for the day it comes out of “under active development” state so that I can migrate from NextCloud to it.