Consider adopting a version scheme that indicates stability

[ryantm]

Hello.

I work on the nixpkgs packaging project, and we package burp. We ran into an issue where our policies indicate we should package the latest stable release, but our semi-automatic packaging updating tools cannot determine if a particular burp version is stable.

It is great that you provide stability information on the news page, and I'm hoping you can consider adopting a version numbering scheme that can indicate the stability of the release. For example, GNOME has a stable/unstable version policy that you could adopt.

Adopting a scheme like this would allow us to add a rule for burp to the Repology rules which will color-code the version number on the burp Repology page and make the information available in the Repology API, which we use to help improve nixpkgs.

Thanks for your consideration, and please let me know if you have any additional questions about this.

Sincerely,
Ryan Mulligan

[grke]

Hello,

Thanks for you message. I am happy to do simple things to make your life easier.

I guess to transition to the suggested scheme, I need to make 2.2.x stable, then start developing on 2.3.x. Then when 2.3.x is stable, release 2.4.0 and skip to 2.5.x for development.
Because the odd middle numbers means unstable.
Let me know if I understood the scheme and that this is correct.

I release monthly, so it might be a few months before 2.2.x becomes stable.

[ryantm]

Thank you! Yes, it looks like that would match the scheme that some GNOME projects use. It is very easy to write a regular expression that checks if the middle version is even and call those stable.

[grke]

Hello,

2.2.16 is now the 'stable' version.
2.3.0 is the 'latest' version.

Therefore, I am now operating to the version scheme suggested, and can close this issue.

Thanks!