Follow semver versioning paradigm

Feature Requests
1

The idea is:

Follow container release versioning (tagging) paradigm that separate stable (latest) from release candidate (next)

My use case:

We use CD framework that allow us to automatically detect release of new version in an artifact source location to perform future defined actions, like automatic upgrade.
Configuration of framework allow us to define regex mask to identify which version mask we should take into account, for example for production stage we interested to retrieve only latest stable versions while for testing stage we interested in latest release candidate version of component to verify/test our functionality even before such release candidate released as stable.

Usually separation between “stable” and “release candidate” done or by individual artifact tagging or artifact location:

  • component:1.2.3 vs. component:1.2.4-rc.2
  • repo/component:1.2.3 vs repo-test/component:1.2.4

unfortunately that not the case with n8n container artifact as both “stable” and “release candidate” present in same artifact repository and doesn’t differentiated by versioning mask:

Current latest: 1.116.2
Current next: 1.117.0

Artifacts repositories for containers by design support multiple tags for same artifact and that already used by n8n release pipeline, but current implementation is misleading because “release candidate” released even before being treated as stable with same versioning mask as stable.

It would be great if release process of n8n in scope of artifacts versioning would follow some semver paradigm and differentiate those properly, example:

14248a2a18487c3e1669d2e2bfeee797f0648f606e0c168e36ef20c3a1f47eac:1.116.2
14248a2a18487c3e1669d2e2bfeee797f0648f606e0c168e36ef20c3a1f47eac:latest
5194c661f0de5543fc02a25a5bb749bb5c93f6b48400c507954ac1d756545053:1.117.0-rc.1
5194c661f0de5543fc02a25a5bb749bb5c93f6b48400c507954ac1d756545053:next

so there would be no need in any workarounds to detect release of stable/rc version

I think it would be beneficial to add this because:

I see other topics with an similar issues when some workarounds required to detect what is current “stable” and what is current “release candidate/pre-release” versions, having proper separation on artifact tag mask will eliminate problem in its root.

Any resources to support this?

Are you willing to work on this?

Yes I could try to contribute to fix that having enough upvote, but that will affect versioning of product