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?
With low numbers at first (Score:2)
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)
And all of a sudden, the module got users. (I can tell by the amount of email I get
cpants data on major version numbers (Score:1)
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)
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