Curtis Jewell wrote:
IMO X.Y_Z should always be < than X.Y. That is, 1.01 > 1.01_05. This
reads
1.01_05 as "the 5th alpha release of 1.01" just like Firefox 3.6.4 beta 1
will
eventually be followed by Firefox 3.6.4.
I'm sorry, but this section is just *wrong*, IMO. X.Y_Z should always
be > X.Y. Otherwise, you've just broken (at least the release sequence
of) previous versions of the toolchain that make the assumption that a
simple s/_// gets something to compare to that works, without
version.pm. (Module::Build, for example, went 0.3603 to 0.36_04 to
0.3605 just within the past few months. I also remember perl doing
5.005_51 versions in the past during the runup to 5.6.0, as being later
than 5.00504. )
You're right about that. The traditional way to handle alphas in decimals is
X.YY_ZZ -> X.YYZZ. My mistake. And it should probably be left that way.
Which is why we should write this stuff down, perhaps in a spec...
You don't get 1.01_05 as "the 5th alpha release of 1.01", if, once
you're exiting the alpha sequence, you immediately increment to 1.02,
anyway.
That was a recommendation to avoid any possible ambiguity, so the versions are
resistant to a reader not entirely groking the details of alpha versions.
Now, what about vX.YY_ZZ? It appears version.pm is treating it as vX.YY.ZZ,
except if they'd otherwise be equal the alpha loses.
v0.36_04 > v0.36.03
v0.36_04 < v0.36.04
v0.36_04 < v0.36.05
The version.pm docs aren't entirely clear on this point, but don't seem to
contradict it.
The trouble is...
v0.36.1_04 > v0.36.1
The fourth alpha of v0.36.1 is greater than the release of v0.36.1. Which
means you always have to do that double increment which is odd. It means the
proper release sequence is: v0.36.0 -> v0.36.0_01 -> v0.36.1.
It does have the benefit of being a simpler algorithm. 1) Convert _ to . 2)
If equivalent, alpha loses.
Anyhow, I'm not really concerned just so long as its written down, once and
for all, and independently of version.pm.
--
On error resume stupid
