Naming of tags and releases in the github-repo

Feedback
1

for documentation and monitoring we check https://api.github.com/repos/n8n-io/n8n/releases/latest every hour and create issues in our internal ticket-system with the value of “tag_name” if there doesn’t exist one:

repo_url=“https://api.github.com/repos/n8n-io/n8n/releases/latest”

curl -s -L -H “Accept: application/vnd.github+json” -H “X-GitHub-Api-Version: 2022-11-28” ${repo_url} | jq .tag_name -r

normaly, we get

"tag-name": "n8n@2.17.3"

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.

I’ve found Older n8n version marked as "latest" on https://github.com/n8n-io/n8n/releases - which show’s a solution which seems to be also inconsistent and not reliable.

1 Like
2

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.

1 Like
3

strange… was ok for release 2.18.4, broken again for 2.18.5

4

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).

2.19.4 and 2.19.5 still broken.

5

at the moment - fine for 2.20.6

1 Like
6

and broken again for 2.20.7