Any and all chit-chat regarding L3DT.
8 posts • Page 1 of 1
For the next major release L3DT will do away with arbitrary major/minor version numbers and adopt a date-based version number in the YY.MM format, à la Ubuntu. Build numbers will be retained, and will count from the previous release version. Thus, the latest developmental build (uploaded today; Pro only) is version 11.06 dev build 27.
Are there any objections to this change?
Well, it is mostly a matter of taste, IMHO. Personally, I'm more in favour of the good ol' major/minor number counting, though.
- the opportunity to go for a "major number change" (for advertising purposes, when big changes come in) is lost
- 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.
- 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?)
But that is just my weird thinking - not saying these are real objections. If you like YY.MM, certainly go for it. L3DT is your baby
Thanks for your reply. I appreciate getting different views on this subject; it helped show up some aspects I hadn't considered.
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.]
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.
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.
* These numbers are for example purposes only, and do not constitute a prediction or promise. A fanciful guess, perhaps.
Aaron, thanks for considering my remarks.
Yes, under the conditions given here, I - too - can not see anything really hindering (or having even slight negative impact on) a versioning change.
Hahaha, speaking of kooky code names - actually, I like those (when in addition to any number versioning, of course).
Especially those incredibly stupid ones. Brings some fun to the business, imho.
So, looking forward to 11.xx “Confused Chihuahua”
I guess I forgot about the codenames for 11.08, but I promise to introduce a codename for the next release. Do you have any suggestions? I kind of like "Irate Iguanodon". Hmmm..but perhaps I should start with the letter A. "Alarmed Axolotl"? "Apoplectic Archaeopteryx"?
Please feel free to use any naming scheme you like (it doesn't have to be an emotional and hard to spell animal.)
I think you are going too complex. “Confused Chihuahua” is just right. Short, simple and down to earth, just for the common user in all of us. In fact if you don't take it, it will be my next game release codename
You can also use internet memes names: "Piano Cat", "Double Rainbow", etc...
Yeah, I too would keep it basic. Like, no forced alliteration and no alphabet order
('Alarmed Axolotl' is kinda cool, tho. You should build that in somewhere ).
- Confused Chihuahua (imho, this is a MUST for the next - named - release)
Me trying to create some combos here, too:
- Rusty Pretzel
- Purple Bellybutton
- Wet Bison
- Horny Bicycle
- Broken Beer Mug
- Flying Hamster
Ah, and please keep a public history list of all those releases/names somewhere
8 posts • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest