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“."
post
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 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.
For what it is worth, I upgraded without changing anything and it worked perfectly.
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. release.
It should still be 0. 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.
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.
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.
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.
I'm still using photoprism. Or sort of rarely using it. So how's immich in comparison now?
The Android app finally syncs on a background thread, oh my god.... the app is finally usable without waiting for a minute every time!
Ah is that what it was. Everyone was always raving about Immich but it was always so slow for me!
Also if you have a large collection in the hundreds of gigbytes and your db is on a hard disk, you may have to tune Postgres to do more caching in RAM. If its on an SSD, then it's fine. If you have db issues, they'll be obvious in the web app too.
Such a great project, I'm still waiting for the stable declaration before I try and convert the family but it's getting hard, so many good features. Really hoping they don't fall victim to the enshitification cycle.
Open-Source is basically immune to enshitification, because as soon as they start to enshitify the community will fork the project and make a better competitor.
With some exceptions, users need to be able to move their data
You can import from an existing folder (read only if you want) so the barrier to entry is pretty low. Especially if you're doing compose, their helm charts kinda suck though if you're doing k8s I ended up rolling my own.
That's really good to know, thanks!
It doesn't automatically put them into albums that way it just dumps them all. In the main collection. I found a JavaScript that will use the API to create albums from the folder structure and added some features to it. So if you do stand it up and want that just ping me. I need to throw it on git anyway just need to find the original author to credit.
Seems like amazing work! Looking forward to testing if this is a solution I might use instead of Google Photos!
Immich is generally regarded as the self hosted replacement for Google photos, personally I have been happy with nextcloud, it's more basic for photos but still does the job for me.
Yea Nextcloud is rock solid and much more stable, I wish it had the features and trajectory of Immich.
My experience is that Immich is more stable than Nextcloud, despite being 'pre-release'
Nextcloud had bugs that corrupted data several times when I was using it, switched away from it awhile ago because of that. NC also feels slow even with all the tuning they recommend.
I haven't had any stability issues with immich and I've been running it for over a year. Nextcloud has always been pretty slow for me and I've not had that issue with immich.
This. Next cloud was /so/ slow and bloaty for me when I tried it. I also got turned away by their lack of ambition with security that went through lemmy about a year ago. I don't like that they were advertising an encryption feature and then not actually encrypting anything past the first folder level. The feature is fixed now I believe but I didn't like the how nom-chalant that process went. Especially for a program that seems to want to be commercial.
Maybe the slowness was fixed, I should look into it again but my main use case was file storage/backup and syncthing more than manages that with way less overhead
The only slowness I've experienced so far is that the android app can get a bit sluggish when scrolling around in the middle of my timeline, or inside bigger albums. Everything else totally smooth though
If you have a lot of photos, does immich require they all be downloaded locally, or does it fetch them from the server as needed?
It fetches them as needed, much like Google photos. Every photo in the timeline has a little icon on it telling you whether it's on your device or only on the server. You can have Immich installed on several devices and see photos from all of them on any of them no problem
That's great! It's what's been holding me back from other self hosted solutions, is that they seemed to want a full two-way sync. Maybe it's time to make the switch!
Go for it! Doesn't even need that much investment as long as you're familiar with self-hosting. Just install it and see how it goes with new photos, and you can still backfill your old photos later. There is a tool that even lets you migrate your entire Google photos account, including albums, favorites etc super easily from Google takeout
Gah, Nextcloud is missing all the features and is frankly unusable (mobile apps are slow, can't make or view albums, and can't "open with" links on Android at least). My family uses it and my biggest project right now is importing all our stuff to Immich when I finally get the NixOS server ready to replace Ubuntu.
I've been using it for over a year now. It's been a great replacement for me. It scans faces, shows where pictures were taken on the map, has the "this date" thing. 0 regrets.
By "this date" do you mean a notification thing that surfaces photos from this time years ago, etc?
Damn I wanna switch to Immich, but have a lot of self-tagged photos on PhotoPrism. I haven't been able to find a way to safely transfer all manually applied tags, and edited metadata from PhotoPrism to Immich yet. Maybe I'll just have to bite the bullet and write a script myself.
If the image metadata contains tags, they will be imported into immich as well. At least all my Google Photos tags got imported no problem.
I don't see where you need to run a DB migration, it's just a change to the docker-compose file for the path.
Is this not what semver is for? Like making consumers aware that there are breaking changes...
all 32 comments