but sometimes (and at the moment, since 2.17.5) we get
"tag_name": "stable"
so we won’t get informed about new releases.
Why did you change the behaviour of the release-process - tag latest should not point to the relaase latest (as it does now), but to a specific relases-number so it can be identified, which release is the current stable.
welcome to the n8n community @mcg
This sounds like a valid feedback item. I’d add that the main issue is machine-readable version discovery for automation, not just naming preference. Many teams rely on /releases/latest for patch monitoring, ticketing, and compliance workflows, so returning a moving tag like stable instead of a semantic version can break downstream processes. If stable is needed for humans, keeping a separate channel tag while preserving versioned tags in the latest-release API response would be much more automation-friendly.
first release 2.19.3 was fine again, but 1h later it was “broken again” and the latest-tag was attached to a “stable”-version (but internal refering to 2.19.3).
now “latest” goes to a “stable” vesion which is 2.20.7-exp.0 - wtf…
sorry, but your relase-tagging-process seems to be completely broken and inconsistent.
and “stay on a version not tagged as latest” or an older version is no option as in the past a lot of security-issues have been found in older versions - so for some reasons we are “forced” to install the latest version available and track the available updates.
Hi @mcg ! Thanks for voicing your concerns with our current release process.
A few months back we did a major rework on how we do releases to increase velocity and give us better visibility into our releases. During this rework, we modified how we package our releases:
We introduced git pointer tags “beta” and “stable”, which point at the current version of the software published to npm and dockerhub under those tags.
What this meant for releases was that during a version release, we publish 2 releases: One with the semantic version as it’s name and one named stable . What this aims to achieve is that tooling can easily always pull the latest “stable” release of n8n, without having to parse through releases or manual effort: the URL always stays the same `releases/tag/stable`.
During this process, we also changed how we tag “latest” on GitHub releases and landed on having it point to the “stable” tag, whatever version that is. This was due to a narrow-sighted vision that it would help people find the stable release more easily. During further research, I’ve discovered that quite a lot of open source libraries in fact point to the semver version of the release as “Latest”.
As a part of this PR, we are changing the functionality, so that “Latest” should again point to the semantic version, not the “stable” version.
Thanks for your feedback and as we ship this change, I hope it resolves your issues as well.
Ahhh, ok - i thouhgt - as n8n@2.22.0 is already available as a Pre-release ( Release n8n@2.22.0 · n8n-io/n8n · GitHub ) and 2.21.4 for example was released with the comment “No changelog generated. Likely points to fixes in our CI.” and the PR is merged the change is already productive and should work.
ok, so i will be patient and wait for 2.22.x marked as latest…
I can see why this is causing problems. If someone is polling /releases/latest for automation, getting a proper version like n8n@2.17.3 is predictable and easy to track. Suddenly returning just stable breaks that workflow completely because there’s no unique release identifier anymore. From an automation/monitoring perspective, stable feels more like an alias than an actual release tag.
I think it would make more sense if the latest release kept the real version tag, and stable existed separately for people who want a floating reference. Right now it’s hard to know which exact release is actually current without adding extra logic/workarounds.
)
