The Selfh.st roundup for the week of 19 June 2026 leads with Immich, the popular Google Photos alternative that continues to ignore the author’s “desperate pleas for tags on mobile.” Immich is switching to release candidates as it prepares its v3 update, which adds mobile non-destructive editing, workflows, and the ability to use the app as a gallery app on Android. The release-cadence shift is the actual story here, not the feature list. The rest of the roundup is a developer asking a useful question: how do you categorize projects by how they release, and what does that categorization tell you about whether to bet on them?
What release cadence actually tells you
The roundup catalogs seven release-cadence archetypes. “By the Book” projects (Home Assistant is the canonical example) release at a steady monthly cadence with intuitive versioning. “Short Burst” projects occasionally drop a major release followed by 2-3 bug fixes before going dark for several weeks. Immich sits here. “Rapid Fire” projects release major and minor versions very frequently, often a sign of AI assistance or vibe coding. “Group Chat” projects manage multiple apps in one repo and produce noisy release feeds (Ente and Posthog are the biggest examples). “Strong, Silent Type” projects don’t share release notes at all. “Personality” projects have fun with their release names or songs. “Off the Grid” projects don’t publish releases at all.
Looking at the seven archetypes side by side is a useful exercise for anyone running self-hosted software. The cadence tells you things about the project that the README does not. A “By the Book” project is being run by someone who has thought about release engineering as a discipline. A “Short Burst” project is being run by someone with a day job who ships in concentrated bursts when they have time. A “Rapid Fire” project is either being run by a small team moving fast or by an AI-assisted solo developer, and the architecture may not have been thought through at the level a slower cadence would require.
The cadence is not a quality signal on its own. Immich’s “Short Burst” pattern is not a sign of a bad project. Immich is one of the better-maintained self-hosted photo managers in the world. The cadence is a risk signal. If you are betting on a project’s continued existence, a “By the Book” project with regular bug fix releases is a safer bet than a “Short Burst” project that may go quiet for months at a time, even if the underlying code quality is the same.
Immich v3 specifically
The v3 release is significant for two reasons. First, the feature set addresses the three complaints Immich users have had for years: mobile non-destructive editing (so you can edit a photo in Immich without modifying the original file), workflows (so you can chain edits and tag operations the way Lightroom users can), and the ability to use Immich as the default gallery app on Android (so you stop needing Google Photos for the things Immich does not yet cover).
Second, the v3 release marks a transition from “Short Burst” to “Release Candidate.” Release candidates are a different cadence signal: the project is signaling that the next release is feature-complete and only needs bug fixes. The implication is that v3 will ship when it is genuinely ready, not when the developer has a free weekend. That is the kind of process signal that tells you the project has matured into something stable enough to bet on in production.
For Immich users on v2.x (which includes me), the v3 transition is a meaningful migration. The mobile app changes are the largest single shift. The server-side API has been stable enough that existing integrations will continue working, but the database migration is non-trivial if you have a large library. Anyone running Immich in production should plan the v3 migration for a weekend when they have time to debug, not for a Tuesday evening between meetings.
The other releases worth noting
The roundup calls out several other projects beyond Immich. BentoPDF continues its run of dad-joke release notes, which is the kind of low-stakes personality signal that tells you a project is being run by someone who is having fun. Grav is the example of a “Strong, Silent Type” project, with no release notes at all this past week despite shipping a release. Passbolt’s release names and songs are the example of the “Personality” archetype.
The interesting comparison is between BentoPDF and Grav. Both are well-maintained. Both ship on a regular cadence. One communicates with users through humor and the other through silence. The functional outcome for a sysadmin is similar: you can trust that the project is shipping and the releases are safe to install. The communication style does not affect the technical quality, but it does affect whether the broader community understands what is changing in each release.
How to use the cadence taxonomy
If you are running a self-hosted stack with more than ten services, the cadence taxonomy is useful as a triage tool. Go through your services and bucket each one. If you have more than two “Short Burst” projects and more than two “Rapid Fire” projects, your stack is probably higher-maintenance than you think.
A useful starting checklist when auditing your own stack:
- Has the project shipped a release in the last 90 days? If not, the project may be in a quiet phase. Quiet phases are fine for 30 days. They are not fine for 180 days.
- Does the project publish release notes? Silent releases are a signal that the project is being maintained by a solo developer who does not have time for documentation.
- Does the project have a public roadmap? A roadmap is a signal that someone is thinking beyond the next release.
- Does the project have a discussion forum, Discord, or Matrix room? Community is the safety net when the original developer steps away.
- Is the project funded, or is there a clear institutional home? Personal projects run on personal time. Institutional projects run on salaries.
The hidden cost of “Short Burst” projects is that you cannot predict when the next release will land and you may have to scramble to keep up. The hidden cost of “Rapid Fire” projects is that each release may require active testing and configuration updates.
The healthy stack in 2026 looks more like Home Assistant than like Huntarr. Steady, predictable, well-documented. The growth-at-all-costs projects from the 2023-2024 era are aging out, and the projects that survive into 2027 will be the ones that figured out a sustainable cadence.
Trade-offs
The cost of being early on a “Short Burst” or “Rapid Fire” project is real. You get the new features first, but you also get the breaking changes first. The cost of waiting is that you miss the window when the project is most responsive to user feedback. Immich users who reported mobile tagging bugs in v1.x got heard. Immich users who report the same bugs in v3 will be told to file a v4 issue.
The migration cost for Immich v2 to v3 is in the 4-8 hour range for a typical home library (under 50,000 photos). The migration cost for a large library (over 200,000 photos) is closer to 12-16 hours because of the database rebuild and the face-recognition reindexing.
If you are running Immich in production today, plan the v3 migration for a quiet weekend. If you are not running Immich yet and you are considering it, v3 is a good time to start, because the release-candidate cadence signals that the project is approaching a stable long-term state. If you only do one thing from this article, check the release cadence of the projects you depend on and flag the ones that have not shipped in the last 90 days. Those are the candidates for replacement discussions.