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
