perl -MCPAN -eautobundle
you'll see that x.yz is the preferred format,
x, y and z being
integers, not simply digits.
You can always
use x.y_z if you want to emulate
x.y.z. The underscore will
be ignored, being treated as a visual separator for digits,
and your number will be treated as x.yz.
At the moment the x.y.z notation is
interpreted differently if different versions of Perl.
For example, it's a v-string in Perl 5.6.1
and it's translated into a 3 characters string
(not necessarily threee bytes), the first
character having code x, the second having
code y, the third having code z.
So, if you try
perl -e'print 33.34.35'
you'll get !"# in Perl 5.6.1 and
33.3435 in Perl 5.005. The notation
v33.34.35 won't even work in Perl 5.005.
My conclusion is that, for the time being,
x.yz or x.y_z are more backwards
compatible than x.y.z or vx.y.z.
As newer versions of Perl replace the old ones, v-strings
will probably be the preferred way. You can always
require 5.6 in your code and start using them
right now without ambiguity.
The other question, about version numbering schemes, is
more about personal taste. Some developers use even minor
releases for stable versions, odd for development (no pun
intended).
So, for example, Linux kernel 2.4 series are
(supposed to be) stable versions, being 4 an even number,
while series 2.3 used to be the development branch that lead
to 2.4.
Another issue is the starting number, some developers
like to start from 0.x versions (meaning it can be
still experimental), while other feel more
confident and their versions start with 1.x.
Finally, some developers like versions such as 1.03, others
prefer 1.3. A minor change would be 1.04 in the first case
(or maybe even 1.03_1 or 1.03_01 or...)
and 1.31 in the second. It doesn't matter which one you
chose, I think. The important thing, in my opinion,
is preserving a correct numerical progression.
Happy releasing!
-- TMTOWTDI |