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
