Zugg Software :: View topic

Wanderer Joined: 25 May 2006 Posts: 88

Zugg,

I think you might want to rethink the version number of CMUD otherwise it might only serve as ammunition for those people who believe CMUD is simply an upgrade of zMud. I would suggest a nice shiny Version 1.0.0 instead.

Newbie Joined: 29 Aug 2002 Posts: 8

Posted: Sat Jun 10, 2006 11:08 pm

I'll be posting about this in the CMUD FAQ. But I choose 8.00 for an important reason...the reason is that CMUD is compatible with zMUD and uses a newer version of the zMUD scripting engine. In a lot of ways, the zMUD version number is really the version of the scripting system. 8.00 tells people that CMUD is compatible with the 7.21 scripting system, but is newer and has new features.

Calling CMUD 1.0 doesn't make any sense either because it's really not a 1.0 product in any sense. It uses a lot of zMUD modules, such as the mapper.

Some people are just going to call CMUD an "upgrade" no matter what I do. I'm not going to make decisions just because of that. I choose the version number carefully because it makes sense to make people aware that it is a "superset" of the zMUD scripting language.

The new name for the program should be good enough to distinguish it from zMUD. Once you run CMUD, it's pretty clear that it's a different program.

(btw, the version number can be found in the Downloads area where there is a placeholder for CMUD until it's released on Monday).

Newbie Joined: 29 Aug 2002 Posts: 8

Posted: Sun Jun 11, 2006 2:16 am

Thanks! I hope it's worth the wait, even for the first beta.

And btw, I'm open to discussion and more feedback on this version 8.00 issue if anyone else wants to chime in. After all, I still have a few more hours to change my mind (or be convinced) Wink

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

It all depends on which part of the application you decide owns the version number.

If the scripting engine is decided to be the main part of the application with everything surrounding it being 'extras' to it, then it would be the version number. However, being as so much of a scripting system in how it handles its storage, processing, priority, and even syntax has changed from zMud to CMud, wouldn't the CMud scripting engine be considered a technology based off of the zMud scripting engine? If that's the case, then yes, you're dealing with a v 1.0.0 technology that is based off of an existing scripting engine.

If you consider CMud its own new application which is just using the 8.00 version of the zMud scripting engine, then it is definately a 1.00 app.

From a beta point of view: It's very confusing for users that haven't been keeping up with the progress seeing version 8.00 of an app and thinking 'oh, this is in beta testing because its brand new'. 8.00 will generally equate to the application being old, fairly stable, and this just being a new iteration of it. Your average user will possibly be confused by the versioning.

Newbie Joined: 29 Aug 2002 Posts: 8

I think the important thing here is CMUD itself; its version number isn't something worth debating over IMO.

I would assume that people who use MUDs are generally above-average in terms of computing experience. These are the guys who are the least likely to become confused over version numbers. Also, what MUDder hasn't heard of zMUD anyway?

Posted: Sun Jun 11, 2006 5:26 am

Actually, I think I might have been convinced to change it to version 1.0

Part of the reasoning is that it's easy to later change this to 8.0 if that makes sense to people. But it would be a lot harder to go back the other way. So Monday's version will be 1.0.

Wizard Joined: 14 Aug 2004 Posts: 1269

Doesn't the first beta release of new software normally have a version number of BELOW 1.0, with 1.0 being reserved for the first "stable" release? I would be tempted to go with version 0.1 for now.

GURU Joined: 10 Oct 2000 Posts: 4379 Location: USA

Version numbers below 1.0 are normally used before the application reaches beta status. Once it reaches beta, you'll normally see stuff like 1.0 beta 1, 1.0 beta 2, etc. Then, after the beta, they start with release candidate versions.

However, Zugg opts instead to just make beta versions part of the normal version numbers and specify to the user before downloading if it is beta or not.

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

That or use the ol' sourceforge 0.9 number range for pre-release.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

there's always Microsofts 'RC 1' which is just a fancy way of saying 'Beta 1'

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

RC means Release Candidate..Generally version numbers use some sort of major.minor.build scheme, and then there are alpha, beta and release candidates that are exposed to users in that order, generally.

Ie: CMUD 0.9.123 (Internal Only), CMUD 1 Alpha 1, CMUD 1 Alpha 2, CMUD 1 Beta 1, CMUD 1 RC1, RC2, RC3, CMUD 1.0 Final.

Thats a fairly well used standard I believe.

Posted: Sun Jun 11, 2006 10:25 pm

With the upgrades only lasting two years, will there be an option to purchase extra upgrades when you purchase cMud the first time? Or will we have to wait for our 2 years to expire before we can pay for another 2 years?

Posted: Sun Jun 11, 2006 10:37 pm

The store has no option to say that the purchase is now but the time for the licence is in the future. I would imagine that something like this will be needed but for now isn't a priority for Zugg, I think I recall reading something he wrote that said he wouldn't worry about upgrades for about a year.

Beginner Joined: 11 Jun 2006 Posts: 20

Personally, I would have it be CMUD 0.80.

.8 shows its a beta, and the from now on, your second digit can tell people what version of the scriptiing language it is, and your first digit be which version of CMud it is.

So when CMud is no longer beta, and you have made fixes to the GUI but not the scriptiing language it can be 1.8 etc.

Posted: Sun Jun 11, 2006 10:43 pm

Baram, that's a good question. I'll consider adding something to the store to allow you to "pre-purchase" upgrade support. It's a good idea and some other people might be interested.

Regarding versions, I like to try and keep things simple. A simple XX.YY version number is what I like. With zMUD I've attached "a", "b", etc to the end for really minor updates, and I'm going to try and get away from that in CMUD.

I stick with numbers because that's what Windows supports. A Windows EXE version number is in the form a.b.c.d where a-d are all numbers. So this doesn't easily support any scheme with text in it without some conversion routines. For example, the bug tracker that I'm using reports the version in that format, so it's easier for me to just use the same format myself. And using all 4 numbers just gets confusing and is overkill. So I'm sticking with just 2 numbers for now.

And I've never liked the sourceforge 0.9 system...too many projects never get past that, and it doesn't leave much room for other versions before a 1.0 public release. After all, what will you end up with, version 0.999995? or something like that? It's just silly.

And I believe strongly that each version released to the public *must* have a unique version number. I don't like their idea of just leaving the version at 0.9 until it's ready for the 1.0 release. Because with incremental versions you still need to track version numbers for bug reports and stuff.

Some companies use a system where even numbers are internal releases and odd numbers are public releases. But I've never worried about that kind of stuff.

I just simply have my installer script automatically increment the version number at release build time. So each new build that I release to the public gets a new number. Simple and easy.

The only tricky part is determing what's a public release and what's a beta release. And it's actually hard to do that with a version number. After all, just because something is marked "public" doesn't mean it's stable. I've had some "public" releases of zMUD that were worse than beta versions. What people really care about is whether a release is "stable". After all, a good "beta" version might actually be stable enough and become a public release.

I plan to be more careful with this in CMUD. I'll release something as Beta, and only when it's stable will I release something with a new version number that is "public". In other words, there won't be any real difference between the public release and the last beta except the version number. At that point I might decide on a numbering system. But it's a few months before I need to decide how to handle that.

Novice Joined: 21 May 2004 Posts: 32

Since open source software is always freely availble, even before it is finished, and because it is public and more than one person may work on it, it needs version numbers even for work in progress. This is why you see so many open source projects with versions like 0.9 and so on.

Similarly, private teams with more than one programmer also usually need some convention so that everyone knows what point they're at. It could be as little as a build number, but they might also use version numbers to indicate landmarks in their progress, such as when the backend is finished, when the gui is finished, etc.

There are also many different version numbering systems. Just look it up in wikipedia if you want a fairly comprehensive overview of what's out there. In the end, though, all it is is just a set of conventions so that is everyone remains coordinated.

For a project where it's just one programmer there's no need to have any version number at all -- although version control system might prove useful if only as a sort of undo-system and, I think, that they usually use version numbers to identify each change -- until the project is released, and then only under the common assumption that the project will continue to improve. So, if you'd like just imagine that the version Zugg has been working on is 0.9 and what he's releasing is 1.0 or 8.0 or 1.0-beta or 1.0-rc1 or whatever he decides.

Zugg:
Yeah, making the public release identical to the last stable beta release is absolutely necessary, even when it seems that just making a tiny little change won't affect anything else. I'm surprised you hadn't done that with zMUD. It seems like you've learned a lot since then, however, so I'm confident that things with CMUD will go much better for you this time.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

The way I handle software versions (even if they're the first release or a beta release) is: Year.Month.Day.MinutesSinceMidnight

So, where I live it's 21:03 on the 12th of June 2006. That would make my release 6.6.12.1263 ... it's kinda more like a build number than a traditional version I suppose, but works well for me.

Also, nobody in their right mind releases a 1.0 version, because people assume 'oh, first version, this won't be anywhere near refined'. Version 1.0 through 1.whatever is the internal alpha releases :)

So long as the installer has some kinda reference it doesn't matter what version you call it. I mean what's wrong with using "CMUD XP build 0141" as the version? Internal and advertised version numbers don't have to be the same. I mean, when you look at Windows - 95 is 4.0, 98 is 4.1, 2000 is 5.0, xp is 5.1, Vista is 6.0, etc.

So I'm mostly saying 'go with what feels right to you'. Use the 8.x as the internal numbers if it makes things easier for you - you can always market it as 1.0 even though internally it reports 8.0.1.104 *shrug*.

Wizard Joined: 14 Aug 2004 Posts: 1269

If CMUD was a Linux project, "1.0-beta1" sounds good and is the naming convention used by some open source projects. But if having alphabetic characters in the version number doesn't work well on Windows and you, Zugg, want to use an XX.YY version number, I'd just go with version 1.0 and name the installer file something like "CMUD 1.0 Beta Installer.exe". It irritates me no end when installers don't have version numbers in the filename (which happens to be the majority of Windows installers), and adding "Beta" to the filename for Beta versions seems sensible to help diferentiate and make it more obvious which versions are beta versions. Also, you could add something to the "Help, About..." screen, e.g.