Re^2: A Peeve of Great Pettishness

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.)

Comment on Re^2: A Peeve of Great Pettishness

Replies are listed 'Best First'.
Re^3: A Peeve of Great Pettishness by tirwhan (Abbot) on Oct 28, 2005 at 15:58 UTC
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	[reply]

Replies are listed 'Best First'.

Re^3: A Peeve of Great Pettishness
by tirwhan (Abbot) on Oct 28, 2005 at 15:58 UTC

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

[reply]