Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What version numbering scheme to use?

I'm looking for a version numbering scheme that expresses the extent of change, especially compatiblity.

Apache APR, for example, use the well known version numbering scheme

<major>.<minor>.<patch> example: 4.5.11 

Maven suggests a similar but more detailed schema:

<major>.<minor>.<patch>-<qualifier>-<build number> example: 4.5.11-RC1-3732 

Where is the Maven versioning scheme defined? Are there conventions for qualifier and build number? Probably it is a bad idea to use maven but not to follow the Maven version scheme ...

What other version numbering schemes do you know? What scheme would you prefer and why?

like image 667
deamon Avatar asked Jan 12 '10 11:01

deamon


People also ask

What version number should I start with?

Start versioning at 1.0. 0 if: Your software is already used in production. Other users depend on your software and care when the API changes.

What are versioning schemes?

Modern computer software is often tracked using two different software versioning schemes: an internal version number that may be incremented many times in a single day, such as a revision control number, and a release version that typically changes far less often, such as semantic versioning or a project code name.


2 Answers

I would recommend the Semantic Versioning standard, which the Maven versioning system also appears to follow. Please check out,

http://semver.org/

In short it is <major>.<minor>.<patch><anything_else>, and you can add additional rules to the anything else part as seems fit to you. eg. -<qualifier>-<build_number>.

like image 97
sixohsix Avatar answered Sep 24 '22 08:09

sixohsix


Here is the current Maven version comparison algorithm, and a discussion of it. As long as versions only grow, and all fields except the build number are updated manually, you're good. Qualifiers work like this: if one is a prefix of the other, longer is older. Otherwise they are compared alphabetically. Use them for pre-releases.

Seconding the use of semantic versioning for expressing compatibility; major is for non-backwards compatible changes, minor for backward-compatible features, patch for backward-compatible bugfixes. Document it so your library users can express dependencies on your library correctly. Your snapshots are automated and don't have to increment these, except the first snapshot after a release because of the way prefixes are compared.

like image 31
Tobu Avatar answered Sep 24 '22 08:09

Tobu