Plugin Versioning numbers

[un_pogaz]

Originally Posted by DrChiper

As "Release/Major/Minor" is pretty vague, I would suggest:

Feature Release, Feature Enhancement, Feature Fix, Experimental

This will help on determination when some value needs to be bumped-up.

So, although the vast majority of developers have agreed to use a versioning with three number in a vaguly Release/Major/Minor, regarding about the exact meaning of each of its numbers and when increase them... weelllllll, good luck with that: nobody agree on this.
And I realy don't want see or start such debat because it would be a wild hell that will fly very low and very hard.

[DrChiper]

Originally Posted by un_pogaz

So, although the vast majority of developers have agreed to use a versioning with three number in a vaguly Release/Major/Minor, regarding about the exact meaning of each of its numbers and when increase them... weelllllll, good luck with that: nobody agree on this.
And I realy don't want see or start such debat because it would be a wild hell that will fly very low and very hard.

Never dreamed to encounter such a moodily reply on just a suggestion. Did I touched a soft (version) spot? By all means, take the floor and enrich us by your wisdom.

[theducks]

Originally Posted by DrChiper

As "Release/Major/Minor" is pretty vague, I would suggest:

Feature Release, Feature Enhancement, Feature Fix, Experimental

This will help on determination when some value needs to be bumped-up.

Release = Not 100% backwards compatible. eg, like, database structure changes that older version will fail (hopefully, gracefully without damage) on.

Major = ?? New features, Just not supported earlier on in the same release.

[BetterRed]

Originally Posted by PeterT

Any thoughts on standards / techniques that could be implemented to handle these issues?

I don't have much to add, that hasn't already been said.

I don't interpret or attach any significance to version numbers, providing they are orderly. I don't like cute names. Aside: why has there never been a MacOS Esalen.

All I ask is that temporary (experimental, beta, whatever…) versions should not be left lying around in Plugin thread replies if they are superseded by an official or another temporary version. If they can't be removed by the originator for some reason they should report the offending post, or PM a calibre mod with a request they be removed.

---

Originally Posted by JimmXinu

. . .

FYI, semi-related, Github releases want Semantic Versioning (https://semver.org/) these days. Which does allow for extra specificity after the micro number, but doesn't want anything before the version number.

Curious, who 'owns' the Semantic Versioning 2.0.0 document, which has this:

As a solution to this problem [dependency hell], we propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented.

So, who is 'we'… We the people, the royal We, Zemyatin's We

[kovidgoyal]

4 version numbers *might* work, but they haven't been tested. My recommendation is stick with three, community updates (not in first post) should bump the last of the 3 numbers. When an official release of the plugin (first post) is made it should use a 3rd number larger than the community ones or bump the 2nd number.

[kiwidude]

I'm not really understanding what the issue is here to spark all this discussion, but my personal approach as an official author/maintainer is to just make sure I use a number higher than whatever else is out there on the thread in the rare circumstances this happens.

If my last official release is x.y.9 and someone posted an unofficial x.y.10 build on the thread then I would just make my next version x.y.11. Does that mean a gap in the release notes number sequence - sure, but it doesn't matter in the slightest. Would an x.y.9.1 build number by them be a cleaner option - sure, but I'm not going to jump all over someone for using x.y.10 instead. These circumstances (on my plugins at least) are so incredibly rare where someone is posting another build on one of my threads that it's just not worth debating imo.

In my day job - absolutely I have very strict approaches, stick to semantic versioning with major.minor.build.revision etc. But for plugins I am way more casual about it - 0 or 1 for the first number to indicate a not yet released alpha of new plugins vs a released one, the second digit for major feature releases/rewrites such as python version changes, and the third digit for bug fixes/minor new features. Would the sky fall in if I broke my own "rules" just to make sure my next official build has a bigger number than an unofficial one on a thread? No.

[DNSB]

Originally Posted by BetterRed

Curious, who 'owns' the Semantic Versioning 2.0.0 document, which has this:


So, who is 'we'… We the people, the royal We, Zemyatin's We

The Semantic Versioning specification was originally authored by Tom Preston-Werner, inventor of Gravatar and cofounder of GitHub.

If you look at the GitHub site for semver, you will see seven people listed. If you go the the repository, you will see 38 people listed who have contributed. I would suspect those 38 are the "we".