On Mon, 01 Jun 2015 21:07:34 +0200 Dominique Dumont <domi.dum...@free.fr> wrote:
> 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 One style of writing version numbers in Perl is: M.nnn_rrr where M is the major number, nnn is the minor, and rrr is the revision. This works because Perl allows underscores in numbers. And these number can be compare numerically. > - 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 > -- Don't stop where the ink does. Shawn
