Register to post in forums, or Log in to your existing account
 

Play RetroMUD
Post new topic  Reply to topic     Home » Forums » CMUD Beta Forum
Ceres
Wanderer


Joined: 25 May 2006
Posts: 88

PostPosted: Sat Jun 10, 2006 4:36 pm   

Version 8.00?
 
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.
Reply with quote
strawberryeeter
Newbie


Joined: 29 Aug 2002
Posts: 8

PostPosted: Sat Jun 10, 2006 10:40 pm   Re: Version 8.00?
 
Ceres wrote:
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.


This does make a lot of sense, considering that this is a "new" program with a new name.

Also, where did you find out about the version number?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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).
Reply with quote
strawberryeeter
Newbie


Joined: 29 Aug 2002
Posts: 8

PostPosted: Sun Jun 11, 2006 12:22 am   
 
Zugg wrote:
CMUD [...] it's released on Monday


I have been simultaneously praising you and cursing you for writing software that makes me anticipate releases like crazy.

Now I cannot wait until Monday! Thanks again for investing so much time and effort into your MUDding projects; you don't go unappreciated!
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Sun Jun 11, 2006 2:48 am   
 
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.
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
strawberryeeter
Newbie


Joined: 29 Aug 2002
Posts: 8

PostPosted: Sun Jun 11, 2006 4:03 am   
 
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?

Zugg wrote:
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


Sorry Zugg, you'll have to get suggestions from the more hardcore MUDders; I'm just a casual player. I just offer monetary support and patronage for good programs and good ambitions.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Sun Jun 11, 2006 9:21 am   
 
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.
Reply with quote
Kjata
GURU


Joined: 10 Oct 2000
Posts: 4379
Location: USA

PostPosted: Sun Jun 11, 2006 11:42 am   
 
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.
_________________
Kjata
Reply with quote
TonDiening
GURU


Joined: 26 Jul 2001
Posts: 1958
Location: Canada

PostPosted: Sun Jun 11, 2006 5:53 pm   
 
That or use the ol' sourceforge 0.9 number range for pre-release.
Reply with quote
slicertool
Magician


Joined: 09 Oct 2003
Posts: 459
Location: USA

PostPosted: Sun Jun 11, 2006 6:31 pm   
 
there's always Microsofts 'RC 1' which is just a fancy way of saying 'Beta 1'
_________________
Ichthus on SWmud: http://www.swmud.org/
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Sun Jun 11, 2006 9:28 pm   
 
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.
Reply with quote
Baram
Novice


Joined: 23 Apr 2006
Posts: 33
Location: Seoul, Korea

PostPosted: 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?
_________________
Joseph Monk
Working on yet unannounced MUD.
Reply with quote
Taz
GURU


Joined: 28 Sep 2000
Posts: 1395
Location: United Kingdom

PostPosted: 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.
_________________
Taz :)
Reply with quote
Daganev
Beginner


Joined: 11 Jun 2006
Posts: 20

PostPosted: Sun Jun 11, 2006 10:39 pm   
 
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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
vey2000
Novice


Joined: 21 May 2004
Posts: 32

PostPosted: Sun Jun 11, 2006 11:37 pm   
 
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.
Reply with quote
Rainchild
Wizard


Joined: 10 Oct 2000
Posts: 1551
Location: Australia

PostPosted: Mon Jun 12, 2006 11:21 am   
 
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*.
Reply with quote
Seb
Wizard


Joined: 14 Aug 2004
Posts: 1269

PostPosted: Mon Jun 12, 2006 2:17 pm   
 
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.
Quote:
CMUD Version 1.0 Beta

Using zScript 8.0 Beta

The downside is you now have two version numbers to track though. But on the plus side, if there are some GUI changes, you don't have to increment the zScript version number, and so in the forums or the bug tracker, previous GUI versions might be supportable so long as they are using the latest zScript version.
Reply with quote
Display posts from previous:   
Post new topic   Reply to topic     Home » Forums » CMUD Beta Forum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

© 2009 Zugg Software. Hosted by Wolfpaw.net