Best Practice for Versioning of Software

Posted by unwaryquerier on Friday January 29, 2021 @03:44PM
from the self-post dept.

Do many software creators tend for a convention on versioning when releasing software? For example Tomcat right now is v9.0.41. We would like to only update our internal stack when "major releases" occur. Would I wait until 9.1.x? I know some softwares call these LTS, but often that is nowhere to be found on their site.

I think this is probably the type of question that could spiral into a bunch of conjecture, but any insight welcome.

( 3 comments | 8 points | on HN )

Re:Best Practice for Versioning of Software by mtmail on Friday January 29, 2021 @03:50PM (#25962333)

https://semver.org/ describes it best

    Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards compatible manner, and
    PATCH version when you make backwards compatible bug fixes.

Ideally you'd only have to worr about major version change, while all others should be backward compatible.

[ Parent | on HN ]

Re:Best Practice for Versioning of Software by tubularhells on Saturday January 30, 2021 @05:31AM (#25967937)

Just use ISO dating. 20210122, add letters at the end if there was multiple release that day.

This is psychologically better because your opensource project won't be stuck on v0.14 for 12 years like some are.

[ Parent | on HN ]

Re:Best Practice for Versioning of Software by stephenr on Saturday January 30, 2021 @04:04PM (#25972973)

If you’ve made no changes that require incrementing the version number, using a date based version will be no different, except people will know at first glance that it hasn’t changed in 12 years.

[ Parent | on HN ]