- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
For what it is worth, I upgraded without changing anything and it worked perfectly.
The one feature I’ve been waiting on for a while is better face recognition in videos, not only the first frame. When/if this happens I will start using it. They’re discussing it for quite a while though, afraid it won’t happen.
As the title might appear a bit alarmist, saving a click “For most users, there’s nothing to worry about. However, if you’ve manually set a custom relative path for “IMMICH_MEDIA_LOCATION” in your “.env” file, you’ll need to convert it to an absolute path. For example, “IMMICH_MEDIA_LOCATION=./my-library” must become “IMMICH_MEDIA_LOCATION=/usr/src/app/my-library“.”
I wouldn’t think this would cause any data loss either, it just wouldn’t find your media or it would throw an error. Very alarmist indeed.
I’m not sure it’s alarmist; I think this is all a breaking change is.
Anybody updating needs to know their existing config may not longer be supported. Even if the consequences are small, even if not every user will be affected, this update will break some previously acceptable configs. I think that warrants a heads up and a reminder to read the release notes.
Also, Immich warns to read the change log every time you update, because it’s still under very active development.
The new beta timeline is sooo smooth! I finally don’t hate scrolling back to find a specific old photo. The scrolling performance feels completely native to me now.
Actual release notes: https://github.com/immich-app/immich/releases/tag/v1.136.0
The Android app finally does IO on a background thread. 🫠
I’m still using photoprism. Or sort of rarely using it. So how’s immich in comparison now?
I’ve been meaning to give this a try on my Synology.
But breaking changes in a point release? Not cool.
The “breaking change” did not break anything for me. As noted, you have to have a specific and non-default configuration for their to be a problem.
Tbf this is actually version v1.136 .0 and
Disclaimer
- ⚠️ The project is under very active development.
- ⚠️ Expect bugs and breaking changes.
- ⚠️ Do not use the app as the only way to store your photos and videos.
- ⚠️ Always follow 3-2-1 backup plan for your precious photos and videos!
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.
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:
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.
From the release notes:
one of the last breaking changes we want to make before reaching the stable release milestone
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
It’s not that kind of breaking change. It’s a change that won’t affect most people. Only those who chose to use a custom location for their media location and chose to set that to a relative path instead of an absolute one which caused the application to have trouble resolving the paths. The change eliminates a bug by preventing people from doing something that was not intended to be supported. So it’s not a “breaking” change necessarily in the sense that they are changing documented functionality. They are eliminating a way that people can misconfigure the application which may in some cases cause the application to break if someone successfully configured the application in this unintended way.
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.
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.
