http://qs321.pair.com?node_id=105423

dpatrick has asked for the wisdom of the Perl Monks concerning the following question:

I'd like to being releasing some of the modules that I've written that I've been sitting on for lack of documentation. Now my question is, how should I version them? That is, should my numbering go x.xx or x.x.x or what? I know that there is a reason for choosing one and I've read a couple of documents on this, but I'd like to get the opinions of other Perl developers who have been faced with the same dilemma (albeit a small one). Thanks everyone.
dap
  • Comment on Software (Module) Release Numbering Conventions

Replies are listed 'Best First'.
Re: Software (Module) Release Numbering Conventions
by chromatic (Archbishop) on Aug 17, 2001 at 05:47 UTC
    A recent thread on p5p proposed a new perldoc called "perlmodstyle". There's a bit in there about version numbers. See here for the start. (I'd start with x.xx, but don't paint yourself into a corner -- 0.01 is different from 0.1).
Re: Software (Module) Release Numbering Conventions
by trantor (Chaplain) on Aug 17, 2001 at 11:24 UTC

    Check the list of modules installed on your system with

    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

Re: Software (Module) Release Numbering Conventions
by snafu (Chaplain) on Aug 16, 2001 at 22:16 UTC
    Well, I don't think there is any hardened rule or RFC on this but there a standard as far as what your versioning is supposed to mean. That of course being the all-known major.minor.minor_minor.etc. However, I believe that the versioning is really up to the developer. It's ultimately up to you if you want to name your first version of a program as version 5. I wouldn't really recommend that but how is the end user supposed to know? I believe it really is just a way for the developer(s) to maintain the code and to be able to handle revision control a little easier. I have seen some people release their first versions as 0.x probably in anticipation of coming out soon with a better version or perhaps that is just how they want to version their software.

    Some people let their revision control software do the versioning for them. eg. RCS or CVS. I like this because unless you tell the revision control to version your rev differently it just minors it up one (ie 4.1 to 4.2 etc).

    In summary, I believe it is up to you. That's how I've done mine. And I do my versioning with the intent to be able to control my revs a bit better.

    ----------
    - Jim

(tye)Re: Software (Module) Release Numbering Conventions
by tye (Sage) on Aug 17, 2001 at 22:02 UTC

    I'm switching from 1.02_03 to 1.002_003 in order to be compatible with the new v1.2.3 version syntax. This is what I'd suggest to others. If you are extra paranoid, use 101.102_103 so that naive string compares will also work.

            - tye (but my friends call me "Tye")