On Monday 01 June 2015 12:48:26 Daniel Staal wrote: > They mean what they mean to the author of the code. *Many* projects use > MAJOR.MINOR.REVISION, where 'Major' is API/User interface changes, 'Minor' > is features and small changes, and 'Revision' is bugfixes and security > patches. It's probably the most common version number scheme I've seen out > in the wild, and therefore as standard as anything I've seen. Perl itself > uses it. Calling using it a 'bug' is calling the plurality (if not > outright majority) of software out there being bugged by design.
One may consider it a standard: http://semver.org/ Semantic versioning is used a lot in Javascript world. As a Debian developer that package Perl module for Debian, I'd like you to also consider how Perl module versions are translated in downstream distribution like Debian or Fedora. For Debian, a version with 2 fields is not compared numerically: i.e. version 1.3 is lower than version 1.25 and 1.30. You may ask: why should Perl module authors care ? This is simply a way to help us: Debian Perl team maintain more than 2000 modules [1] and it's a lot of work. Having a version that goes down instead of going up require more work on our side (if we spot that the module requires an update). I'd advise: - use 2 or 3 (or more fields) as you wish - assume that numeric comparison does *not* work - always increment major version number if you change version scheme (even if there's no major change in your module, that's not a big problem) Hope this helps [1] http://pet.debian.net/pkg-perl/pet.cgi -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
