use Perl

• With low numbers at first (Score:2)

  by htoug (771)

  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
• Stangely (Score:2)

  by Juerd (1796)

  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.
• cpants data on major version numbers (Score:1)

  by domm (4030)

  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
• What I do... (Score:1)

  by Alias (5735)

  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