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