I do think sub-1.0 version numbers get abused a bit, because many people feel that putting the big 1.0 on something should mean the item is stable and as bug-free as possible, while having every feature one could ever dream of.

I think that's partially a pipe dream, and partially a lack of good planning. When coming up with a feature list, many people draw the 1.0 line when they can't think of any more good features. It should be drawn at a point when the item has all necessary features to accomplish its goal. The other features can be divided into useful chunks with bigger version numbers. A guassian blur filter in a graphics app won't be useful until the filter engine is done, and the engine is useless without a couple of simple filters -- those are things that might be released together under a version.

However, I don't think that sub-1.0 numbers are automatically bad, either. A sub-1.0 version should be, IMO, products that the author feels aren't really ready to be useful, yet. In other words, there are necessary features missing, or said features have not yet been adequately tested.

I would like to see authors with versions out like 0.98 promote to 1.0 when their 0.98 "testing" version hasn't gotten a bug report in months (or years).

++ radiant, in particular for this reasonable tidbit:

<quote>
(the 1.0 line) should be drawn at a point when the item has all necessary features to accomplish its goal.
</quote>

I suppose I'll have to revisit some of my CPAN modules. You've given me something to dwell on.

Well I think your point makes some sense, but not in all contexts.

For instance, when I am building something for $work which we are selling in some way, then I will slap a 1.0 onto it for the first release. This is because it is the first release to a $paying, non-technical audience. If we do a major upgrade at some point, we will bump the version appropriately, depending upon the "size" of the upgrade.

When I am building a module for internal use within these $work products, that may or may not get released to CPAN, I take a different approach. My "clients" for this kind of work are fellow developers, they are not a dazzled by the bright shiney number 1.0. For these modules, I start at 0.01 and I increment each version by 0.01. Why? Because I know that those numbers don't really mean that much to a developer. A developer should only care that the module works, that is has a solid set of tests, and if possible has been field tested by the author (aka - deployed in prod). I would sooner use a 0.01_a module which had +95% test coverage and had been deployed in a production environment for 6 months or more, than I would use a 3.0 module which does not meet those same criteria.

-stvn

Absolutely not. A version number of >=1.0 in a library/perl module suggests to me that the modules is sufficently tested/debugged and the interface is stable and there will be no changes made that could affect programs which use it. Clearly this is not the case for many of the <=1.0 version modules on CPAN, therefore they are versioned correctly as they are.

One of the tenets of free software that works particularly well IMO is Release early, release often. You want to put out software which is incomplete or incompletely debugged and designed, to make use of the community feedback on where you should concentrate your efforts in improving it. Releasing software in the alpha and beta stage is essential to this process, however you also want to warn your users about the stage the software is in so they don't end up putting your beta-level software into production use and getting fired when the product blows up in their face. Keeping a version number below 1.0 is an easy warning to say "expect changes or even bugs".

I think you're getting a little carried away with your own personal definition of what version numbers mean. There is no worldwide standard for them.

A version number of >=1.0 in a library/perl module suggests to me that the modules is sufficently tested/debugged and the interface is stable and there will be no changes made that could affect programs which use it.

The only > 1.0 projects where you can count on no future changes that might affect your program are the ones that get abandoned.

Clearly this is not the case for many of the <=1.0 version modules on CPAN, therefore they are versioned correctly as they are.

Not clear at all. Some very commonly used modules have had < 1.0 version numbers for years.

Version numbers are marketing, plain and simple. All that you can tell from them is that one version came out later than another (and you can't even tell that with products that have multiple live branches, like mod_perl.)

There is no worldwide standard for them.

Agreed. But lot of software projects (inside and outside the perl community) follow a scheme similar to what I have described, therefore I find it a useful method of looking at software when evaluating it at a single glance. And I think it is a scheme which it would be useful to follow in new projects, rather than releasing all software at 1.0 as the OP demands.

Some very commonly used modules have had < 1.0 version numbers for years.

Again, I agree. Reread what I said, I did not say all modules <1.0 are unstable.

The only > 1.0 projects where you can count on no future changes that might affect your program are the ones that get abandoned.

OK, I could have phrased that better, what I meant was that I generally expect version >1.0 libraries to not break the interface on minor-version upgrades, so that I can safely upgrade the library without breaking my program. I have no such expectation of software with a version number <1.0.

Version numbers are marketing, plain and simple.

Version numbers can be (and often are) more than marketing. Take the major/minor numbering scheme used by Perl and the Linux kernel as an example which works well (and has been adopted by many other projects). The version number can communicate information about the status of a piece of software, which is useful.

And I think the distinction I made in my post about free and commercial software versioning is important. If a company offers me a product and demands money for it, then yes, I'd expect it to be at least at v 1.0. I'd also expect it to be relatively bug-free and feature-complete, so that it's useful to me. If a piece of FLOSS is initially released at version 1.0, I'd suspect the author has missed out on one of the most important advantages of free software, that of community feedback at an early stage.


Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

I can see the point that has been mentioned of 'get it out there and the community will give you feedback', but IT IS out there, and people do expect to use it.... and DO use it. MNSHO is that somebody who wants to put buggy, featureless stuff out there should either go to work in Redmond or should add their work to the Acme:: subtree. Maybe if we create a FUBAR::RealTree::foobar tree for sub-1.0 modules, that would be the right way to get them out there for feedback and improvement but keep them from falling into the hands of the unwary who expect them to actually work.

There probably IS a happy medium, and I'm sure most authors worth paying attention to do strive to make their stuff at least perform its feature set correctly. I have found this to be the case with modules and programs I've used, for the most part, and I certainly think the open source release-and-act-on-feedback-model is a huge improvement over "We'll fix it in 5.0".

I'm glad that made you feel better.

I'm also used to seeing '1.0' as the first real|production|valid release; my prejudice is that release 0.3.0 is, at best, in beta.

I also don't like release "numbers" that seem to be include random alphanumeric characters.

I've other rants, too, such as modules released with no documentation. Sorry, but I can't be bothered trying to figure out what Purple::Blovinator does by reading the code.

Since I wrote this I found out that there is actually a "purple" module, but not a Purple module. &abashed_grin;

You've just lit a fire in me to create module Purple::Blovinator and submit it to CPAN.

The name is sooo cool that it shouldn't be commented!

I agree! We need this module desperately.

Blovination is an extremely useful and powerful tool

emc

While we're having a rant about documentation ...

If you're writing a module tell me exactly what it does in the simplest terms possible, sure it obvious to you what it does, but while it might solve my problem I won't know what it does unless you tell me!

There are too many modules whose documentation is typically:

Name

Purple::Blovinator

Description

Implements lib_blovinator on the purple operating system. See lib_blovinator's documentation for interface.

Firstly, I have no idea what lib_blovinator does. It may solve my problem. Secondly, while you may be able to map a C API to perl simply by reading the C docs, not everyone can - including myself.

OK, I feel better now.

I fail to see the problem. If you can't understand lib_blovinator's documentation, it's unlikely to solve your problem anyway.

Sure, it would be nice if there's more documentation. But people getting software for free who still whine it's too difficult for me, you must put more work into it, because I won't really irk me.

Perl --((8:>*

Different projects use different version number strategies. Some version numbers just approach π (TeX) or ε (Metafont(?)). Others use numbers with the date in them (DNS records), or use the age of the module as the date. Yet other projects just copy whatever next CVS number their files get. And there are projects that use major.minor.patch numbers, carefully adjusting the right numbers at the right time. And not every one is consistent. Perl went from "5.005_XX" to "5.6.X". Solaris went "... 2.4, 2.5, 2.5.1, 2.6, 7, 8, 9, ...". Windows went "3.1, 95, 98, 2000, XP" - although I guess they were more names than version numbers.

I prefer to use "major.minor" version numbers, starting at version "1.1", increasing the major number if and only if the interface breaks compatability.

*

And even then not anyone degrees. Is version "3.9" older or new than version "3.10"? I'd say older, but CPAN thinks that "3.10" is older than "3.9" (because it assumes "3.9" is short for "3.900" and "3.10" is short for "3.100").

...but (oops: opening self to charges of pouring gasoline on fire)... some authors, properly IMO, publish work-in-progress to obtain feedback. I can't fault using sub 1.0 version numbers on those known (or believed) to be IMperfect or INcomplete.

But (reverting to agreeability_mode) yeah; numbering a release with a sub 1.0 version number if it passes testing and is ready to do (something | anything ) useful seems to me to be inappropriate, and likely founded on "going along with current style" or "low self-esteem."

I have <looks at search.cpan> four distributions on the CPAN with version numbers less than 1. Three I inherited from other people and have decided to keep their version numbering scheme, on the grounds that suddenly jumping from version 0.12 to version 1 would be just as misleading about the state of the software as it is to leave it alone. The fourth - Data::Transactional - is all my own work and is at version 0.1 because it has at least one documented major bug, perhaps one documented minor bug, and it solicits feedback about the internals (of which I have received none).

On the other hand, the interface is stable, it does something useful, and it passes its tests.

• Java: after version 1.4, you have version 5; there are pretty substantial differences between "minor" version numbers.
• OS X: they advertise the difference between 10.3 and 10.4 as a monumental event, which is not what one would expect just by looking at the version numbers.
• Several historic Microsoft products: version 1 was completely useless; version 2 was an alpha version; version 3 is almost usable, and version 5 or 6 may actually be pretty good...
• CPAN: many authors start at 0.01 or 0.1, and most of them never make it to 1.0, even for some very stable modules. There is usually a belief that a change in the integer part of the version number implies large changes with break of backward compatibility. It is very rare to see version numbers greater than 4.0 (except for some that use something like 20051028 as the version number).
• Pugs: approaches a certain value (2pi) asymptotically.

The version number isn't informative; wishing it were is... well... just wishing. It's there for the author's (or authors') convenience. You might as well ignore it. What should matter to you is the documentation (including change history, and todo notes if they are available) and the code, should you feel the need to inspect it prior to use.

-sauoq
"My two cents aren't worth a dime.";

The most common "standard" that people claim to support, but rarely really do, is:

• A major version number. Changes in this are a form of warning that backwards compatibility is being intentionally broken. The magnitude of the number has psychological value but no real meaning, except that zero is a special case: zero means use at your own risk because an interface hasn't been established yet that the author is willing to stick to.
• A minor version number. This gets bumped every time the author believes that some new functionality or bugfix is blessed for use by others.
• A patchlevel, of uncertain meaning. The magnitude doesn't matter, as long as it's always increasing. Might be a build number, or a date, or whatever. Generally zero means the initial public-ish release of that major.minor.

Well, get over it. If it does something useful with a vaguely reasonable API, smack a 1.0 on it. Most CPAN authors spend quite a bit of time polishing things up before their first CPAN release, so calling it 0.1 is disingenuous. And even if you're hesitant about the API, well... you released it, right? So you're saying you'd like other people to try using it? Through the current API, however incomplete and ill-thought-out? Well, then, you must think that something can be accomplished through it, so why not bless it with a big "1.0" even though you're certain that you'll quickly have an interface change afterwards?

If you realize that some part of the API is a huge mistake and should be done totally differently -- what's so bad about calling the next one 2.0? I've found that, as painful as the quick 1.0 -> 2.0 -> 3.0 -> 4.0 succession feels, it almost always slows down dramatically sooner than you expected from the initial phases. And if anyone's using it, you'll have to make enough fixes to produce 2.1, 2.2, 2.3, ..., and by the time you do the 3.0, it'll feel about right.

The "release early, release often" argument is fine, and there really are cases where pre-1.0 versions are more appropriate. But how many projects/modules really have a community of developers or users before they're actually usable for anything? Not many. Users and developers only show up after you've demonstrated the promise with a sample app.

Besides, users are more attracted to versions 1.0 and later, and you want users, right? Right?

While I undestand that version numbers are arbitrary, it makes me nervous to see an establish product start installing .2s, .3s, .6s, etc as dependencies.

I've yet to have any issues with any packages, but as a n00b, I'm worried about becoming dependant on something then finding out I'm in over my head.

As my manager is fond of saying, "Its not whats wight or wrong, its the preception"... though I rebel against this as much as possible :)

As computer folks we are trained to start counting at zero, yes? So ideally your first release should be...

$VERSION = 0.00;

...with the only need of a decimal point being to indicate when some future upgrade should be considered to break the historical user interface. Thus, from releases 0.01 through 0.99 you have only fixed bugs and added features, but not broken any prior features from the user's perspective.

So...a version number of 1.00 signifies you have already gone and broken faith with prior users once before! How are we to trust you now?

Then comes yet another day when once again you look at your code and say, "Dear gods! What was I thinking?" and re-do significant parts, requiring the users to employ previously trusted features differently than they have become accustomed. You then release that 3rd incarnation as version 2.00, indicating the uncivil boundary crossing. Thereafter, versions 2.00 through 2.99, should only fix bugs and add new features...until your next divine epiphany changes your world view and inspires you change course significantly once again, to the annoyance of prior users with a version 3.00...and so forth.

I actually read that concept somewhere else and merely regurgitate it here for you all to point at and gag over. My little contribution, having written only one taudry module in my own right Chart::EPS_Graph.pm. Following the scheme detailed above I released it as version 0.01. Retch all you like, it works just fine. I use it regularly. My documentation, however, is fairly verbose. The tests serve as complete usage examples.