[DBIx-Class-Devel] version numbering scheme

fREW Schmidt frioux at gmail.com
Tue Feb 26 17:53:29 GMT 2013


Ribasushi asked me to respond, so here's my POV:

1) meaningful version numbers are good
2) our current scheme is complex/vague enough to warrant a change
3) the first number only implies a breaking change

I partially agree with abraxxa's conclusion.  Some time, maybe now,
we should switch to the version scheme:

   sprintf("%d.%03d%03d", $breaking, $major, $minor);

The only thing we are breaking is the meaning of our numbers.  I doubt
that any time in the future we will distinguish between small features
and bugfixes (also it's what catalyst does which I don't see anyone
complaining about.)

DBIC will be in maintenance mode once databases stop changing and we have
a perfect abstraction of SQL (etc.)  I don't see this happening
ever, and thus don't see the point of having a half-big endian version
scheme where the first byte is wasted on an unimportant maint flag and
the other 6 bytes are in a more reasonable, meaningful order.

To be clear, I *DO NOT* think we should increase $breaking unless there
is a breaking change.  So 1.000000 (1.0.0) get's released at some point
soon, just so the versions are easier to understand.  The constructor
rewrite lands, we release 1.001000 (1.1.0.)  This is (almost) what
catalyst does and it's clear, it works, and it doesn't get us into
chrome/firefox/linux dist versionitis where the first number is giant.
Moo does the same thing, every single one of my modules (except the acme
one) do the same thing: https://metacpan.org/author/FREW/

Additionally, I think the numbers should ONLY increase monotonically.
So you never go from 1.1.0 to 1.10.0 unless there were at least 9
releases inbetween that added major features.  The $minor one will
obviously increase quickly due to dev rels, but that's ok.  It's at
the end of the number because it matters the least.  Similarly, the
first number matters the most because when that changes it means
"watch the fuck out this will break your shit".  That actually means
we *should* have increased that number in 0.08205, since we completed
a deprecation cycle.

Ultimately I think this is a bikeshed.  I have my opinions and will
probably never listen to anyone else unless I have to; I imagine that
others feel the same.  I don't think this is worth arguing much over,
which is effectively what I told abraxxa when he brought this up with
me on IRC.  I like "my" scheme and would love if DBIC used it, but I
would certainly not take my toys elsewhere or even get mad if we used
abraxxa's scheme where the last three bytes will rarely get used
or the current dbic scheme where the first byte never gets used.

--
fREW Schmidt
http://blog.afoolishmanifesto.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://lists.scsys.co.uk/pipermail/dbix-class-devel/attachments/20130226/862b8f0b/attachment.pgp


More information about the DBIx-Class-Devel mailing list