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.
You can argue the correctness or not of the guidelines put out at semver.org, but I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.
I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.
That wasn’t the argument.
Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:
⚠️ The project is under very active development. Expect bugs and changes.
Go to the repo and you’ll see the README, which states at the very top:
⚠️ The project is under very activedevelopment.
⚠️ Expect bugs and breaking changes.
If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.
The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.
As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.
I don’t think there’s any room to argue
Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:
8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.
It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.
If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.
I don’t think they’re using semver. That’s literally what I’m complaining about. I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.
As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.
Wonderful. Good for them. Good for you. Good for everyone who disagrees with me. Just not for me. And that’s just my opinion, man. And that should be ok with you for me to have it.
I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.
Because you didn’t say that; you said “Breaking changes in a point release? Not cool” and later “I’m basing this off the guidelines at semver.org.”
I’m paraphrasing your comments from memory, to be clear, so apologies if I misquoted you.
It certainly felt to me like you were assuming that this project was using semver and was not following it well, not that you wouldn’t want to use a project that receives this many breaking changes / that doesn’t follow semver. Those complaints both make a lot more sense to me - and I’ve seen many people say similar things about Immich in the past. In fact, it’s a big part of why I haven’t migrated from Photoprism to Immich myself - in this regard they’re complete opposites.
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.
You can argue the correctness or not of the guidelines put out at semver.org, but I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.
That wasn’t the argument.
Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:
Go to the repo and you’ll see the README, which states at the very top:
If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.
The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.
As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.
Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:
It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.
I don’t think they’re using semver. That’s literally what I’m complaining about. I genuinely don’t understand why people here are taking it so hard that I wish the Immich devs were using semver.
Wonderful. Good for them. Good for you. Good for everyone who disagrees with me. Just not for me. And that’s just my opinion, man. And that should be ok with you for me to have it.
Because you didn’t say that; you said “Breaking changes in a point release? Not cool” and later “I’m basing this off the guidelines at semver.org.”
I’m paraphrasing your comments from memory, to be clear, so apologies if I misquoted you.
It certainly felt to me like you were assuming that this project was using semver and was not following it well, not that you wouldn’t want to use a project that receives this many breaking changes / that doesn’t follow semver. Those complaints both make a lot more sense to me - and I’ve seen many people say similar things about Immich in the past. In fact, it’s a big part of why I haven’t migrated from Photoprism to Immich myself - in this regard they’re complete opposites.