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“.”
How is it alarmist? Those are breaking changes that require attention
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.
The Android app finally does IO on a background thread. 🫠
Actual release notes: https://github.com/immich-app/immich/releases/tag/v1.136.0
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.
I’ve been meaning to give this a try on my Synology.
But breaking changes in a point release? Not cool.
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.
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.
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.
🍻
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. 🙂
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.