XML-LibXML's 2.* Versioning Scheme: Please Advise.

Hi all,

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.

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?

What do you recommend?

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Parody of "The Fountainhead" - http://shlom.in/towtf

He who reinvents the wheel, will understand much better how a wheel works.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
0
shlomif
5/31/2012 8:31:21 AM
perl.module-authors 1604 articles. 0 followers. Follow

12 Replies
1147 Views

Similar Articles

[PageSpeed] 9
Get it on Google Play
Get it on Apple App Store

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?"
0
david
5/31/2012 10:57:39 AM
On 05/31/2012 10:31 AM, Shlomi Fish wrote:
> 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?

Also note that, at least concerning Perl, it looks like 4, but is really 
2 :-)

That's why, for example, you can't say "use 5.10;", but you have to say 
"use 5.010;".

cheers,
Aldo


0
dada
5/31/2012 12:24:22 PM
--Sig_/RhNrI8xLa+YN772Y5kQIDvU
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This will be part of my talk at YAPC.

I recommend you use 2.xxx, where xxx is always zero-padded.

    our $VERSION =3D '2.001'; # 2nd version of revision 2
    our $VERSION =3D '2.420'; # 421st version of revision 2

It has the following properties:

* It is fully compatible with the advice in
    * perlmodstyle
    * version.pm
    * "strict" version rules
  <http://p3rl.org/perl5120delta#Version-number-formats>
    * <http://www.dagolden.com/index.php/369/> =C2=B9
    * Perl::Critic::Policy::ValuesAndExpressions::ProhibitVersionStrings
    * Perl::Critic::Policy::ValuesAndExpressions::RequireNumericVersion
* It completely prevents:
    * trailing zeros from disappearing because it's a quoted string
    * the confusion about 1.10 < 1.9 (Perl says that's true, other
  system say the opposite) because there are always exactly 3 digits
  after the decimal mark, so any(numeric,lexicographical,naturalsort)
  comparison has the same result
    * the confusion about 5.10.1 =3D=3D 5.010001 (and the variant mentioned
  by Aldo) since there is only a single representation because there
  are only enough decimal places (namely 3) for one portion of semver
  (or Perl's notion thereof)
    * the confusion around v-strings which after all those years still
  are such an usual and (on average) poorly understood data type
    * that ugly v-prefix in the distro package name
* It is fully compatible with downstream packaging toolchains (RPM
  specfile macros and the like).
* It is incompatible with semver. Not a big loss, for the reasons
  already mentioned by David.

=C2=B9 Avoid underscore version numbers and you don't need that ugly `eval`.
Simply use the `TRIAL` feature for trial releases instead.
<https://pause.perl.org/pause/query?ACTION=3Dpause_04about#convention

--Sig_/RhNrI8xLa+YN772Y5kQIDvU
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/HePAACgkQFtlTdOX00Hr7CQCdHkgf7urghmEvbFJIbMXvPI8T
RFMAn1W+D79fFRqet8qANyuBN+8Muj5q
=LT1e
-----END PGP SIGNATURE-----

--Sig_/RhNrI8xLa+YN772Y5kQIDvU--
0
daxim
5/31/2012 1:57:52 PM
UHJldHR5IG11Y2ggY2FtZSBhYm91dCB0aGlzIGluZGVwZW5kZW50bHkgZm9yIGJpb3BlcmwsIGJ1
dCBtYXliZSBpdCdzIGEgYml0IGxpa2UgY29udmVyZ2VudCBldm9sdXRpb24gOikgDQoNCmJpb3Bl
cmwgdXNlcyB0aGUgMS54LnkgdmVyc2lvbmluZyBhbmQgaXQgaGFzIGJlZW4gYSByZWFsIHBhaW4g
dG8gZGVhbCB3aWxsIG92ZXIgdGhlIHllYXJzLiAgV2UndmUgZGlzY3Vzc2VkIHRoaXMgb3ZlciB0
aGUgeWVhcnMsIGFuZCBzaW5jZSB3ZSdyZSBicmVha2luZyBiaW9wZXJsIHVwIGludG8gc21hbGxl
ciByZWxlYXNlcyB3ZSdsbCBiZSBzd2l0Y2hpbmcgb3ZlciB0byBhIDIueCByZWxlYXNlLCBwcmV0
dHkgbXVjaCB0aGUgYXMgdGhlIGJlbG93LiAgDQoNCm15IDJjDQoNCmNocmlzDQoNCk9uIE1heSAz
MSwgMjAxMiwgYXQgODo1NyBBTSwgTGFycyBEyarhtIfhtIThtIvhtI/htKEg6L+q5ouJ5pavIHdy
b3RlOg0KDQo+IFRoaXMgd2lsbCBiZSBwYXJ0IG9mIG15IHRhbGsgYXQgWUFQQy4NCj4gDQo+IEkg
cmVjb21tZW5kIHlvdSB1c2UgMi54eHgsIHdoZXJlIHh4eCBpcyBhbHdheXMgemVyby1wYWRkZWQu
DQo+IA0KPiAgICBvdXIgJFZFUlNJT04gPSAnMi4wMDEnOyAjIDJuZCB2ZXJzaW9uIG9mIHJldmlz
aW9uIDINCj4gICAgb3VyICRWRVJTSU9OID0gJzIuNDIwJzsgIyA0MjFzdCB2ZXJzaW9uIG9mIHJl
dmlzaW9uIDINCj4gDQo+IEl0IGhhcyB0aGUgZm9sbG93aW5nIHByb3BlcnRpZXM6DQo+IA0KPiAq
IEl0IGlzIGZ1bGx5IGNvbXBhdGlibGUgd2l0aCB0aGUgYWR2aWNlIGluDQo+ICAgICogcGVybG1v
ZHN0eWxlDQo+ICAgICogdmVyc2lvbi5wbQ0KPiAgICAqICJzdHJpY3QiIHZlcnNpb24gcnVsZXMN
Cj4gIDxodHRwOi8vcDNybC5vcmcvcGVybDUxMjBkZWx0YSNWZXJzaW9uLW51bWJlci1mb3JtYXRz
Pg0KPiAgICAqIDxodHRwOi8vd3d3LmRhZ29sZGVuLmNvbS9pbmRleC5waHAvMzY5Lz4gwrkNCj4g
ICAgKiBQZXJsOjpDcml0aWM6OlBvbGljeTo6VmFsdWVzQW5kRXhwcmVzc2lvbnM6OlByb2hpYml0
VmVyc2lvblN0cmluZ3MNCj4gICAgKiBQZXJsOjpDcml0aWM6OlBvbGljeTo6VmFsdWVzQW5kRXhw
cmVzc2lvbnM6OlJlcXVpcmVOdW1lcmljVmVyc2lvbg0KPiAqIEl0IGNvbXBsZXRlbHkgcHJldmVu
dHM6DQo+ICAgICogdHJhaWxpbmcgemVyb3MgZnJvbSBkaXNhcHBlYXJpbmcgYmVjYXVzZSBpdCdz
IGEgcXVvdGVkIHN0cmluZw0KPiAgICAqIHRoZSBjb25mdXNpb24gYWJvdXQgMS4xMCA8IDEuOSAo
UGVybCBzYXlzIHRoYXQncyB0cnVlLCBvdGhlcg0KPiAgc3lzdGVtIHNheSB0aGUgb3Bwb3NpdGUp
IGJlY2F1c2UgdGhlcmUgYXJlIGFsd2F5cyBleGFjdGx5IDMgZGlnaXRzDQo+ICBhZnRlciB0aGUg
ZGVjaW1hbCBtYXJrLCBzbyBhbnkobnVtZXJpYyxsZXhpY29ncmFwaGljYWwsbmF0dXJhbHNvcnQp
DQo+ICBjb21wYXJpc29uIGhhcyB0aGUgc2FtZSByZXN1bHQNCj4gICAgKiB0aGUgY29uZnVzaW9u
IGFib3V0IDUuMTAuMSA9PSA1LjAxMDAwMSAoYW5kIHRoZSB2YXJpYW50IG1lbnRpb25lZA0KPiAg
YnkgQWxkbykgc2luY2UgdGhlcmUgaXMgb25seSBhIHNpbmdsZSByZXByZXNlbnRhdGlvbiBiZWNh
dXNlIHRoZXJlDQo+ICBhcmUgb25seSBlbm91Z2ggZGVjaW1hbCBwbGFjZXMgKG5hbWVseSAzKSBm
b3Igb25lIHBvcnRpb24gb2Ygc2VtdmVyDQo+ICAob3IgUGVybCdzIG5vdGlvbiB0aGVyZW9mKQ0K
PiAgICAqIHRoZSBjb25mdXNpb24gYXJvdW5kIHYtc3RyaW5ncyB3aGljaCBhZnRlciBhbGwgdGhv
c2UgeWVhcnMgc3RpbGwNCj4gIGFyZSBzdWNoIGFuIHVzdWFsIGFuZCAob24gYXZlcmFnZSkgcG9v
cmx5IHVuZGVyc3Rvb2QgZGF0YSB0eXBlDQo+ICAgICogdGhhdCB1Z2x5IHYtcHJlZml4IGluIHRo
ZSBkaXN0cm8gcGFja2FnZSBuYW1lDQo+ICogSXQgaXMgZnVsbHkgY29tcGF0aWJsZSB3aXRoIGRv
d25zdHJlYW0gcGFja2FnaW5nIHRvb2xjaGFpbnMgKFJQTQ0KPiAgc3BlY2ZpbGUgbWFjcm9zIGFu
ZCB0aGUgbGlrZSkuDQo+ICogSXQgaXMgaW5jb21wYXRpYmxlIHdpdGggc2VtdmVyLiBOb3QgYSBi
aWcgbG9zcywgZm9yIHRoZSByZWFzb25zDQo+ICBhbHJlYWR5IG1lbnRpb25lZCBieSBEYXZpZC4N
Cj4gDQo+IMK5IEF2b2lkIHVuZGVyc2NvcmUgdmVyc2lvbiBudW1iZXJzIGFuZCB5b3UgZG9uJ3Qg
bmVlZCB0aGF0IHVnbHkgYGV2YWxgLg0KPiBTaW1wbHkgdXNlIHRoZSBgVFJJQUxgIGZlYXR1cmUg
Zm9yIHRyaWFsIHJlbGVhc2VzIGluc3RlYWQuDQo+IDxodHRwczovL3BhdXNlLnBlcmwub3JnL3Bh
dXNlL3F1ZXJ5P0FDVElPTj1wYXVzZV8wNGFib3V0I2NvbnZlbnRpb24NCg0KDQo=
0
cjfields
5/31/2012 2:07:00 PM
I'm curious -- I know PAUSE checks the $VERSION in the package (I ran into
a "thought that was inherited" problem once), but isn't it using the the
version key in the META.json or META.yml files for its indexing? So while
getting the version information right in $VERSION is important, wouldn't
getting it right in Build.PL or dist.ini (or whatever tool you use) be
equally important?

     -john

On Thu, May 31, 2012 9:07 am, Fields, Christopher J wrote:
> Pretty much came about this independently for bioperl, but maybe it's a
> bit like convergent evolution :)
>
> bioperl uses the 1.x.y versioning and it has been a real pain to deal will
> over the years.  We've discussed this over the years, and since we're
> breaking bioperl up into smaller releases we'll be switching over to a 2.x
> release, pretty much the as the below.
>
> my 2c
>
> chris
>
> On May 31, 2012, at 8:57 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
>
>> This will be part of my talk at YAPC.
>>
>> I recommend you use 2.xxx, where xxx is always zero-padded.
>>
>>    our $VERSION = '2.001'; # 2nd version of revision 2
>>    our $VERSION = '2.420'; # 421st version of revision 2
>>
>> It has the following properties:
>>
>> * It is fully compatible with the advice in
>>    * perlmodstyle
>>    * version.pm
>>    * "strict" version rules
>>  <http://p3rl.org/perl5120delta#Version-number-formats>
>>    * <http://www.dagolden.com/index.php/369/> ¹
>>    * Perl::Critic::Policy::ValuesAndExpressions::ProhibitVersionStrings
>>    * Perl::Critic::Policy::ValuesAndExpressions::RequireNumericVersion
>> * It completely prevents:
>>    * trailing zeros from disappearing because it's a quoted string
>>    * the confusion about 1.10 < 1.9 (Perl says that's true, other
>>  system say the opposite) because there are always exactly 3 digits
>>  after the decimal mark, so any(numeric,lexicographical,naturalsort)
>>  comparison has the same result
>>    * the confusion about 5.10.1 == 5.010001 (and the variant mentioned
>>  by Aldo) since there is only a single representation because there
>>  are only enough decimal places (namely 3) for one portion of semver
>>  (or Perl's notion thereof)
>>    * the confusion around v-strings which after all those years still
>>  are such an usual and (on average) poorly understood data type
>>    * that ugly v-prefix in the distro package name
>> * It is fully compatible with downstream packaging toolchains (RPM
>>  specfile macros and the like).
>> * It is incompatible with semver. Not a big loss, for the reasons
>>  already mentioned by David.
>>
>> ¹ Avoid underscore version numbers and you don't need that ugly `eval`.
>> Simply use the `TRIAL` feature for trial releases instead.
>> <https://pause.perl.org/pause/query?ACTION=pause_04about#convention
>
>
>
>


0
jgamble
5/31/2012 3:34:02 PM
--Sig_/rmoKS+3xrlSEZWRsmGxXqsf
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

> wouldn't getting it right in Build.PL or dist.ini (or
> whatever tool you use) be equally important?
I never had to think about that. See my distros in the wild, they don't
mention the distro version number there.

* EUMM <http://search.cpan.org/dist/Module-CPANTS-Analyse/Makefile.PL>
* M::B <http://search.cpan.org/dist/PostScript-Barcode/Build.PL>
* M::I <http://search.cpan.org/dist/Mediawiki-Blame/Makefile.PL>

Being virtuously lazy (DRY), I let the build tools autodetect from the
main module of the distro.

* <http://p3rl.org/ExtUtils::MakeMaker#VERSION_FROM>
* <http://p3rl.org/Module::Build::API#module_name>
* <http://p3rl.org/Module::Install#all_from>

--Sig_/rmoKS+3xrlSEZWRsmGxXqsf
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk/HopYACgkQFtlTdOX00Hp6uACfSVqr2nsYxqzre4CrMDm31KC2
ve4An0nOBelQGSPonf5NDJcvgSB2thR1
=CmeO
-----END PGP SIGNATURE-----

--Sig_/rmoKS+3xrlSEZWRsmGxXqsf--
0
daxim
5/31/2012 4:55:38 PM
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.

Doesn't matter which one of the above you select, if you keep the same scheme through all your releases, and your 
version is a number. I'd vote for #2 if you ask me. Or even 2.xxx. If you really need next major version, you can make 
it 3.xxx.

> 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?

This is the worst idea someone could ever do about versions in Perl. This and v2.x.y. Don't use it. 2.x.y is not a 
number, 2.x.y != '2.x.y', comparison is tricky, etc etc etc. Especially if you already have 1.xx version numbering for 
older versions of XML-LibXML.

-- 
S.T.
0
stro
5/31/2012 5:34:34 PM
--0016e6d626504594af04c158b2db
Content-Type: text/plain; charset=ISO-8859-1

From a non-perl-centric viewpoint, the vast majority of projects I work
with nowadays abide by the semantic versioning concept (your v4) :

http://semver.org/

You lose the version's value as an actual number, but you gain more
standard readability as to what the version means, which is something that
I consider more valuable.

--
Jarrod Overson

On Thu, May 31, 2012 at 1:31 AM, Shlomi Fish <shlomif@shlomifish.org> wrote:

> Hi all,
>
> 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.
>
> 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?
>
> What do you recommend?
>
> Regards,
>
>        Shlomi Fish
>
> --
> -----------------------------------------------------------------
> Shlomi Fish       http://www.shlomifish.org/
> Parody of "The Fountainhead" - http://shlom.in/towtf
>
> He who reinvents the wheel, will understand much better how a wheel works.
>
> Please reply to list if it's a mailing list post - http://shlom.in/reply .
>

--0016e6d626504594af04c158b2db
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

From a non-perl-centric viewpoint, the vast majority of projects I work wit=
h nowadays abide by the semantic versioning concept (your v4) :<div><br></d=
iv><div><a href=3D"http://semver.org/">http://semver.org/</a></div><div><br=
>

</div><div>You lose the version&#39;s value as an actual number, but you ga=
in more standard readability as to what the version means, which is somethi=
ng that I consider more valuable.</div><div><br></div><div>--</div><div>

Jarrod Overson<br><br><div class=3D"gmail_quote">On Thu, May 31, 2012 at 1:=
31 AM, Shlomi Fish <span dir=3D"ltr">&lt;<a href=3D"mailto:shlomif@shlomifi=
sh.org" target=3D"_blank">shlomif@shlomifish.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

Hi all,<br>
<br>
earlier today I uploaded XML-LibXML-1.99 and since the 1.* releases had two=
<br>
trailing digits, the next version will be past 2. This is a good to switch =
to a<br>
better versioning scheme, with more digits after the first dot, which will =
give<br>
us more air to breath.<br>
<br>
I&#39;m asking you what the advantages and disadvantages of the following s=
chemes:<br>
<br>
1. &quot;2.xxyy&quot; - &quot;xx&quot; are the major/new-feature versions, =
while &quot;yy&quot; are for bug<br>
fixes/maintenance versions.<br>
<br>
2. &quot;2.xxxyyy&quot; - same as before only with three digits each.<br>
<br>
3. &quot;2.xxyyy&quot; - same as before only a hybrid approach that will gi=
ve a zero in<br>
the middle in case there are less than 100 maintenance versions.<br>
<br>
4. &quot;2.x.y&quot; - I use this for my open source C projects and some of=
 my CPAN<br>
modules and perl 5 and Parrot use it as well. Is it well supported with the=
<br>
CPAN toolchain?<br>
<br>
What do you recommend?<br>
<br>
Regards,<br>
<br>
 =A0 =A0 =A0 =A0Shlomi Fish<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
-----------------------------------------------------------------<br>
Shlomi Fish =A0 =A0 =A0 <a href=3D"http://www.shlomifish.org/" target=3D"_b=
lank">http://www.shlomifish.org/</a><br>
Parody of &quot;The Fountainhead&quot; - <a href=3D"http://shlom.in/towtf" =
target=3D"_blank">http://shlom.in/towtf</a><br>
<br>
He who reinvents the wheel, will understand much better how a wheel works.<=
br>
<br>
Please reply to list if it&#39;s a mailing list post - <a href=3D"http://sh=
lom.in/reply" target=3D"_blank">http://shlom.in/reply</a> .<br>
</font></span></blockquote></div><br></div>

--0016e6d626504594af04c158b2db--
0
jsoverson
5/31/2012 5:49:36 PM
On Thu, May 31, 2012 at 10:49:36AM -0700, Jarrod Overson wrote:
> From a non-perl-centric viewpoint, the vast majority of projects I work
> with nowadays abide by the semantic versioning concept (your v4) :
> 
> http://semver.org/
> 
> You lose the version's value as an actual number, but you gain more
> standard readability as to what the version means, which is something that
> I consider more valuable.

You lose that the moment someone decides to rename Linux 2.6.bignum to
3.0 for no good reason.  So really, no matter what the ideal, in
practice it doesn't mean a damned thing.

-- 
David Cantrell | Minister for Arbitrary Justice

  When one has bathed in Christ there is no need to bathe a second time
      -- St. Jerome, on why washing is a vile pagan practice
         in a letter to Heliodorus, 373 or 374 AD
0
david
5/31/2012 7:12:37 PM
On Thu, May 31, 2012 at 08:12:37PM +0100, David Cantrell wrote:
> On Thu, May 31, 2012 at 10:49:36AM -0700, Jarrod Overson wrote:
> > From a non-perl-centric viewpoint, the vast majority of projects I work
> > with nowadays abide by the semantic versioning concept (your v4) :
> > 
> > http://semver.org/
> > 
> > You lose the version's value as an actual number, but you gain more
> > standard readability as to what the version means, which is something that
> > I consider more valuable.
> 
> You lose that the moment someone decides to rename Linux 2.6.bignum to
> 3.0 for no good reason.  So really, no matter what the ideal, in
> practice it doesn't mean a damned thing.
> 

Which is why some people have moved to integer versions, based on the date,
with extra digits tacked at the end to allow for multiple releases on
the same day: a package released today would have the version 2012060101.
(to be read as 2012-06-01 release 01).

If that matters, it will remain a 32 bit integer until the year 2147,
at which time we can hope to have solved the issue of version numbers
and integer size for a while. And probably a few other of mankind's
current issues.

These version numbers do not convey any actual meaning, but give you
a very precise notion of how old this module is.

(I'm using the scheme Lars described. Having at least a major version
number allows to convey *some* information.)

-- 
 Philippe Bruhat (BooK)

 None suffer so much in a war as those who strive to end it.
                                    (Moral from Groo The Wanderer #51 (Epic))
0
philippe
5/31/2012 11:22:26 PM
* Philippe Bruhat (BooK) <philippe.bruhat@free.fr> [2012-06-01 01:25]:
> On Thu, May 31, 2012 at 08:12:37PM +0100, David Cantrell wrote:
> > On Thu, May 31, 2012 at 10:49:36AM -0700, Jarrod Overson wrote:
> > > You lose the version's value as an actual number, but you gain
> > > more standard readability as to what the version means, which is
> > > something that I consider more valuable.
> >
> > You lose that the moment someone decides to rename Linux 2.6.bignum
> > to 3.0 for no good reason.  So really, no matter what the ideal, in
> > practice it doesn't mean a damned thing.
>
> Which is why some people have moved to integer versions, based on the
> date, with extra digits tacked at the end to allow for multiple
> releases on the same day: a package released today would have the
> version 2012060101. (to be read as 2012-06-01 release 01).

Which is why File::Slurp is now version 9999.19 on the CPAN.

If you’re going to use date-based versions I suggest V.YYmmNN as the
format, with V being some arbitrary major version number. So e.g. the
first release cut during May 2012 would be 2.120501.

(I omit the day since a limit of 99 releases a month is reasonable but
lengthening the version number by another 2 digits would not be.)

Then you can change your mind about the versioning scheme without having
to contend with 9999999999.xxxxxx (or else abandoning the namespace so
that you get to start over). Simply bump the major version to switch to
another convention.

You lose the easy intuitiveness of plain date-based versions, of course,
and thus a major attraction, but you do retain the same information they
provide (save for the exact age in days, which is meaninglessly precise
in the grand scheme of things).

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>
0
pagaltzis
6/1/2012 6:55:57 PM
Hi all,

On Thu, 31 May 2012 11:31:21 +0300
Shlomi Fish <shlomif@shlomifish.org> wrote:

> Hi all,
> 
> 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.
> 

thanks to everybody who replied. Since there seems to be a general consensus
that the double dot version ("2.x.y" or "v2.x.y") are not a good idea for CPAN
modules, I will go with a 2.xxyyy scheme instead where "xx" adds new features
and the "yyy" is for bug-fixes or patch releases.

Thanks again!

Regards,

	Shlomi Fish


-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
List of Portability Libraries - http://shlom.in/port-libs

It does not mean what I think it means, but it means what *you* think it
means.

Please reply to list if it's a mailing list post - http://shlom.in/reply .
0
shlomif
6/1/2012 9:32:18 PM
Reply: