On Thu, May 31, 2012 at 11:31:21AM +0300, Shlomi Fish wrote:
> earlier today I uploaded XML-LibXML-1.99 and since the 1.* releases had two
> trailing digits, the next version will be past 2. This is a good to switch to
> a
> better versioning scheme, with more digits after the first dot, which will
> give
> us more air to breath.
>
> I'm asking you what the advantages and disadvantages of the following schemes:
>
> 1. "2.xxyy" - "xx" are the major/new-feature versions, while "yy" are for bug
> fixes/maintenance versions.
>
> 2. "2.xxxyyy" - same as before only with three digits each.
>
> 3. "2.xxyyy" - same as before only a hybrid approach that will give a zero in
> the middle in case there are less than 100 maintenance versions.
There's little point in attempting to encode meaning into version
numbers, as everyone will have their own idea of what it means. People
who care about what has changed and how much it has changed can look at
the documentation, your VCS, and the CHANGELOG.
> 4. "2.x.y" - I use this for my open source C projects and some of my CPAN
> modules and perl 5 and Parrot use it as well. Is it well supported with the
> CPAN toolchain?
It's supported, but supporting it is a gigantic pain in the arse and it
will break older versions of some toolchain stuff. I consider it to be
a bug, it just happens to be a common enough bug that it needs to be
grudgingly supported.
> What do you recommend?
Versions should be *numbers* (and so contain at most one decimal point),
they should be zero or positive, they should not be subject to rounding
errors on any reasonable system (so 1.000000000000000000000000000000003
should not be used, for example), and they should go up. Other than that
I don't care.
--
David Cantrell | Minister for Arbitrary Justice
"There's a hole in my bucket, dear Liza, dear Liza."
"WHAT MAKES YOU SAY THERE IS A HOLE IN YOUR BUCKET?"
