On Thu, 2 Dec 2004, jon wrote:
Also check the numbers...I think I'm in favor of beginning to advance our version numbers higher up like firefox did, thunderbird, and gimp. Although numbering is quite superficial, maybe we should start doing full point release releases after 0.40. Maybe the next one is 0.50, then next 0.60, etc. (HINT: I'm working on the roadmap rework right now)
I prefer the major.minor[.point[.subpoint...]] format we're currently using and which is relatively standard in Open Source.
Treating version numbers like decimal numbers is a bad idea because you invariably run out of room, and engender unrealistic expectations about how close a specific future version is. I've been through that on some other projects and it's not pretty.
It's psychologically better for the project if we don't pretend that version numbers have predictive (rather than just descriptive) value, lest we find ourselves pressured to either extend a release cycle for too long, or rush things, because of the "expected" next version number.
Let's say we were using decimal version numbers and had reached 0.90...
Consider what would happen if we had to postpone roadmap items to maintain decently short release cycles like we did for 0.40 (effectively moving things out a release), it'd really suck if we'd been implying that 1.0 would necessarily be the next release.
Our options at that point would be:
* delay the release until all 1.0 features were done
(In my experience, overly long release cycles can really hurt a project; I'm sure you all could feel the strain from the length of the 0.40 release cycle. Now just imagine how much worse that would be with all the expectations of a 1.0 release looming...)
* release an unsatisfactory 1.0 before it's really done
(needless to say this would generate a lot of ill will)
* start using versions that asymptotically approached 1.0
(I think people would feel rather cheated by an 0.95 release under those circumstances)
I don't expect there to be that much slippage in our roadmap, but some future items are exceptionally ambitious and we need to allow for that.
The major version is our "marketing" number; let's not let marketing infect our release process, which is the inevitable result of "sexing up" minor release numbers.
Yes, if we keep the major.minor.point format, some people are going to think that e.g. 1.5 comes after 1.42. Maybe we should start including the implicit point release (.0) on our minor release numbers as other projects do.
...and yes, I admit the version number jump after the Sodipodi fork was rather cheap. :P
-mental