Re: Take care with version numbers (eg DBD::Pg)
On Jul 12, 2010, at 8:54 PM, Greg Sabino Mullane wrote: Doesn't that mean perl -MDBI -e 'print $DBI::VERSION' cannot indicate if you've got a dev version or a final release? Yes, thank god. Because that's not where that information should be! David
Re: Take care with version numbers (eg DBD::Pg)
On Thu, 8 Jul 2010 15:56:38 -0700, David E. Wheeler da...@kineticode.com wrote: Underscores should be banned from version numbers. Full stop. In principle, and as an end-user I would wholeheartedly agree, but the way CPAN /and/ CPANTESTERS is currently set up, having _XX support is a huge win. The moment I release a module Foo-X.YY_ZZ, it is excluded from commands that would otherwise `see' it as an upgrade, like $ cpan Foo It will simply be skipped, as CPAN sees this as a developer release. On the CPANTESTERS side however, the testers DO pick it up and give me feedback on how this developer release behaves in the big wide unknown world. I /do/ have Linux, HP-UX, AIX and a few windows/Strawberry devel environments, but CPANTESTERS adds to those NetBSD, FreeBSD, ActivePerl on windows, OS/X and maybe even more. That info is very nice to have. Additionally, most CPANTESTERS reports inform me about errors I forgot to take out regarding not-yet installed modules (dependencies I did not declare or debugging modules I forgot to take out). Best, David -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Take care with version numbers (eg DBD::Pg)
On 07/08/10 17:08, David E. Wheeler wrote: On Jul 8, 2010, at 9:38 AM, Jens Rehsack wrote: Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. I think, the best way out would be a hard consensus and CPAN reindex. The closest thing to a concensus is represented in David's blog post: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ Have a look how David use the version numbers in Module::Build - he seems to be unable to be strict on himself (no critic, just mentioned). He describes how module authors can deal with the non-boring version numbering in Perl ... Best example for can't have everything. Do I understand the intension of the original mail right, that it should start a new wave of enlightenment about version objects? Jens
Re: Take care with version numbers (eg DBD::Pg)
On Fri, Jul 09, 2010 at 07:47:00AM +0200, H.Merijn Brand wrote: On Thu, 8 Jul 2010 15:56:38 -0700, David E. Wheeler da...@kineticode.com wrote: Underscores should be banned from version numbers. Full stop. In principle, and as an end-user I would wholeheartedly agree, but the way CPAN /and/ CPANTESTERS is currently set up, having _XX support is a huge win. Agreed. But there's no need to use them *in modules*. The dev releases of DBI 1.612 have *distro* versions 1.611_9x (greater than 1.611 but less than 1.612) but $DBI::VERSION is 1.612. Tim.
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 8:31 AM, Tim Bunce wrote: FYI On Thu, Jul 8, 2010 at 3:48 AM, Nigel Horne n...@bandsman.co.uk wrote: ! DBD::Pg2.6 2.17.1 Let's review version number math: 2.6 = 2.60 2.17.1 = 2.017001 2.60 2.017001 Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. Best, David
Re: Take care with version numbers (eg DBD::Pg)
On 07/08/10 16:32, David E. Wheeler wrote: On Jul 8, 2010, at 8:31 AM, Tim Bunce wrote: FYI On Thu, Jul 8, 2010 at 3:48 AM, Nigel Hornen...@bandsman.co.uk wrote: ! DBD::Pg2.6 2.17.1 Let's review version number math: 2.6 = 2.60 2.17.1 = 2.017001 2.60 2.017001 Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. Best, David I think, the best way out would be a hard consensus and CPAN reindex. This might break some things in the first way - but my experience as Perl module packager for pkgsrc packaging system is, that most authors do not react until things fail (and many of them do not react then). But this will touch the sacred cow of downward compatibility ... We can't have both. Jens
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 9:38 AM, Jens Rehsack wrote: Looks like it should have been 2.6.0: 2.6.0 = 2.006001 2.17.1 = 2.017001 2.006001 2.017001 Version number suck. And clearly, three-version numbers suck harder. I think, the best way out would be a hard consensus and CPAN reindex. The closest thing to a concensus is represented in David's blog post: http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/ Fortunately, version number parsing is gradually becoming stricter. You can only use strictly-formatted version numbers in `use MODULE VERSION` and `package MODULE VERSION` (as of 5.12). It will be at least 10 years before loosely-parsed version numbers are deprecated, though. And perhaps not then. Besides which, if my META.yml says DBD::Pg: 2.6 It assumes decimal notation (2.600), not three-digit (2.006). It has no way to tell that I really mean the latter. This might break some things in the first way - but my experience as Perl module packager for pkgsrc packaging system is, that most authors do not react until things fail (and many of them do not react then). But this will touch the sacred cow of downward compatibility ... We can't have both. No, we can't, alas. Best, David
Re: Take care with version numbers (eg DBD::Pg)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Looks like it should have been 2.6.0: Yep, there is no such thing as version 2.6 of DBD::Pg. I think, the best way out would be a hard consensus and CPAN reindex. Consensus on what exactly? Perhaps it would be good if the mixing of two and three dot versions on the same check was treated as a severe error and caused an automatic FAIL report. I can't see a case where using both forms would ever be desired. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007081302 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkw2Bf4ACgkQvJuQZxSWSsitqACg/ci1wC6pC3KIsQ1EXctbhg57 /jcAnRrGkbzhvcoIZTZy6UlGdUN8uuDW =I0v4 -END PGP SIGNATURE-
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 10:09 AM, Greg Sabino Mullane wrote: Perhaps it would be good if the mixing of two and three dot versions on the same check was treated as a severe error and caused an automatic FAIL report. I can't see a case where using both forms would ever be desired. In my META.yml, I'll use three-digit notation for modules that use it (DBD::Pg) and decimal for those that don't (DBI). It might be useful for the version validation code to complain if I specify decimal and the module uses three-digit (or vice versa). But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Best, David
Re: Take care with version numbers (eg DBD::Pg)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I can't see a case where using both forms would ever be desired. In my META.yml, I'll use three-digit notation for modules that use it (DBD::Pg) and decimal for those that don't (DBI). Right, I didn't mean to imply you can't mix and match across modules. It might be useful for the version validation code to complain if I specify decimal and the module uses three-digit (or vice versa). Could be a lot of work, yes, but it would certainly catch things like the existing RWDE problem (as would my proposal by itself). But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Good point, but hopefully such changes are a very rare and momentous event (as was the case with DBD::Pg). Version 1.49 (the last of the two dot versions for those playing at home) is *severely* deprecated. One of the reasons DBD::Pg jumped to 2.0.0 was to prevent any version comparison confusion, as even Perl's wacky versioning tools cannot deny that 2 1. :) - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201007081340 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkw2DsMACgkQvJuQZxSWSsjeLACgsakZH/iVhwltaCqXOMOmcF8e ZBkAnjJlhWBgf0jWMJiRsPJDUkXWbxF2 =MhsI -END PGP SIGNATURE-
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 10:46 AM, Greg Sabino Mullane wrote: But then that would screw things up for modules that unfortunately changed their versioning algorithm. I would no longer be able to require DBD::Pg 1.49, for example, even thought that's perfectly valid. Good point, but hopefully such changes are a very rare and momentous event (as was the case with DBD::Pg). Version 1.49 (the last of the two dot versions for those playing at home) is *severely* deprecated. One of the reasons DBD::Pg jumped to 2.0.0 was to prevent any version comparison confusion, as even Perl's wacky versioning tools cannot deny that 2 1. :) A lot of folks changed without any momentous reason. So this suggestion, frankly, is right out. Frankly, I consider even momentous reason dubious. Pick a version and stick to it. I myself maintain a module or two with hinky version numbering systems because I inherited them and see no benefit to changing. Best, David
Re: Take care with version numbers (eg DBD::Pg)
My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :)
Re: Take care with version numbers (eg DBD::Pg)
On Jul 8, 2010, at 3:29 PM, Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. And thus may be X.Y or X.YY as well. Short, sweet, simple. Yeah, I'm with you. All of my modules use this format. (Except Bricolage. Don't ask.) Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) That's one louder, isn't it? David
Re: Take care with version numbers (eg DBD::Pg)
Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) You mean now? 1.611 came out on April 29th. Or did you mean the completely different 1.611_93? Confusing! And that points to an example of something else that should become common practice for numbers. Projects that have any version X.Y_Z should never also have a version X.Y for the same X plus Y. Instead, the Y should always increment when moving between a developer release and a production release. See how DBD::SQLite does things for an example that I think is better. This is also analogous to Perl's own versioning X.Y.Z scheme, where there are never developer and production releases with the same Y. Its much less confusing that way. It also avoids the confusion of relating 1.002003 to 1.002_003, say; are those the same version or different versions? So, if the next DBI release after the latest 1.611_93 is going to be a stable release, then keep the current plan for it to be 1.612. Then, when making a subsequent dev release, call it 1.613_1 or 1.613_001 or such. Does that not make more sense? -- Darren Duncan
Re: Take care with version numbers (eg DBD::Pg)
Underscores should be banned from version numbers. Full stop. Best, David On Jul 8, 2010, at 3:46 PM, Darren Duncan wrote: Tim Bunce wrote: My take on this, for the record, is to prefer two part numbers in the form X.YYY where YYY never has a trailing zero. Short, sweet, simple. Tim. p.s. No one commented on the DBI going from 1.609 to 1.611 :) You mean now? 1.611 came out on April 29th. Or did you mean the completely different 1.611_93? Confusing! And that points to an example of something else that should become common practice for numbers. Projects that have any version X.Y_Z should never also have a version X.Y for the same X plus Y. Instead, the Y should always increment when moving between a developer release and a production release. See how DBD::SQLite does things for an example that I think is better. This is also analogous to Perl's own versioning X.Y.Z scheme, where there are never developer and production releases with the same Y. Its much less confusing that way. It also avoids the confusion of relating 1.002003 to 1.002_003, say; are those the same version or different versions? So, if the next DBI release after the latest 1.611_93 is going to be a stable release, then keep the current plan for it to be 1.612. Then, when making a subsequent dev release, call it 1.613_1 or 1.613_001 or such. Does that not make more sense? -- Darren Duncan
