Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

claes (1758)

claes
  (email not shown publicly)
http://www.surfar.nu/
AOL IM: claesjacobsson@mac.com (Add Buddy, Send Message)

Journal of claes (1758)

Sunday April 04, 2004
12:08 PM

Distribution versioning on CPAN?

[ #18195 ]
I've been thinking lately about how authors version their distributions and what managers think of using software with < 1.00 version numbers.

I, like probably most other Perl developers, trust that a distribution on CPAN with a version number below 1.00 is still usable and considered safe.

But, if I was a non Perl-programming manager who had to make the decisions I would be more skeptical on relying on software that didn't have a "stable" version number. "stable" in this context meaning 1.0 or later. I believe that the fact that there are so many distributions on CPAN with a version below 1.0 (some of mine included) could scare the decision makers off and instead of embrace and extend just go on developing their own internal modules that does the same thing.

The problem that we are seeing this is because h2xs sets 0.01 as the initial version of the module it creates and many authors are just too lazy to even bother thinking about if this should be considered stable. Are there any guidelines in the Perl community when a distribution should receive a >= 1.00 version number?

So my question to all of you is:

How do you version your distributions and why?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I like the idea of having less than 1.00 versions while the API is stabilising, but I feel that it should jump to above 1.00 when everything is firmed up and you are reasonably confident that you will be backwards compatible.

    I just haven't followed that style in my own module (DBD::Ingres) - mostly because I felt that I could'nt have DBD::Ingres at above 1.00 when the DBI was at 0.xx, and there has'nt been a good opportunity since to raise the number (a major jump in version number should also signify a maj

  • I version my modules 0.01, 0.02 and so forth until I think they're ready for production use. Then I add 1 to the version number. This way, DBIx::Simple went from 0.10 to 1.11.

    And all of a sudden, the module got users. (I can tell by the amount of email I get :) Apparently many are indeed afraid to use 0.0x releases.
  • Hi!

    slightly off-topic, but here's a list of distribution of major version numbers of modules on CPAN (where a major version number is something like $version=~/^(\d+)\..*/:

    sqlite> select count(version_major) as cnt,version_major from cpants group by version_major order by version_major;
    cnt version_major
    ---------- -------------

    4073 0
    1752 1
    272 2
    69 3
    22 4
    17 5
    2

  • I generally start at 0.01 and I think it's generally appropriate that the module starter scripts to that.

    My general guideline is that I click a module over to 1.00 when:

    1. I'm happy the API is clean and complete
    2. There's proper tests and docs
    3. There's no dodginess left inside it
    4. It's been a year since I achieved the above
    5. I haven't got any significant bug reports in that time.

    At that point, I do a slight clean up of the POD for spelling and grammar, update the bits and pieces like the Makefile.PL t