Hi Miko,
Thanks for your reply. I appreciate getting different views on this subject; it helped show up some aspects I hadn't considered.
the opportunity to go for a "major number change" (for advertising purposes, when big changes come in) is lost
That’s true, but I’ve not really been using version numbers for that purpose; the last major version number change was in 2003. Since then, I’m not sure there have been sufficiently drastic user-visible changes between versions to ever justify a step in the major version number. For sure, the addition of the plugin-based architecture was a huge change in
L3DT v2.4b, but at the time it had no user-visible effect, so I didn’t get a major version number step (it didn't even get a minor number step, it was just revision B!) The addition of the Sapphire 3D renderer in
L3DT 2.5 was also a big change, but it was only one aspect of what is otherwise quite a large program. Moreover, Sapphire was still quite primitive in v2.5, and was subsequently improved incrementally in v2.5a, v2.5c, v2.6, 2.7, and 2.9. All together, Sapphire would warrant a major version step, but since it has been developed gradually over a period of years, there was never that single moment where a major version number seemed appropriate.
I guess with YY.MM, we'll have a major version step every year. That's got to be an improvement over two in eight years, and none in the past seven. [
Sheesh, I just realised that this Sunday marks eight years since v1.0 was released. I'm feeling old now.]
people can automatically "deduct" the apps "age". Let say, you've got a good and stable product, but by its name, it would e.g. state "huh, I'm already two years old". Not that positive, from "sales people view", maybe.
I’d agree that could be a problem if the time between releases was long (e.g. a couple of years; who wants L3DT 2006?), but most L3DT releases last for about 6-12 months before the next is available, so it’s never like I’m selling a really old product. L3DT 10.08 doesn’t sound too old, does it? My feeling is that YY.MM suits frequent, incremental updates quite well, and better than an arbitrary major/minor system.
I suppose a flip-side of your argument is that date-based version numbers also remind users when they’re using an old version, and possibly that it’s time to look for an update. I hasten to add this possible (minor) windfall wasn’t actually a consideration in the decision, as I only thought of it just now.
- changing numbering concept during an app's life time is always a mess (IMHO). Yeah, I know, there are lots of examples ("no, it is not version 7.1. That is now called 2010. And the next one will be "Codename Imperator" - which is equivalent to 8.0 or 2011.5 " - errrr - what?)
True, it is a bit messy at the changeover. However, it will happen once, and there won’t be any kooky code names (“Confused Chihuahua” or whatnot) or conversion hijinx (“2.9 is equivalent to 10.08”). The version numbers will simply jump about 9 majors from 2.8, 2.9 to 11.08, 12.04, etc*. I think/hope that can be explained with a minimum of confusion or fuss.
Anyhoo, thanks again for the feedback. I shall consider the matter further, but for now, I must nap.
Cheers,
Aaron.
* These numbers are for example purposes only, and do not constitute a prediction or promise. A fanciful guess, perhaps.