|
|
Post by Alexander on Jan 22, 2004 12:49:10 GMT -5
Mouse, 1) its not another redesign, its renamed and going to do the stuff totally differently, 2) no betas, only comming out when its ready, 3) build numbers start from scratch cause it is in effect a new program idea, 4) the only thing that you will recognise from the old bot is the about and options menu which looked pretty good  PS : im not redesiging it again, i took it off the beta list purely because of the comments of people like you... so you will have to find someone else to critisize while im working on the program  |
|
|
|
Post by Lazer on Jan 22, 2004 12:55:00 GMT -5
/me sighs
|
|
|
|
Post by Alexander on Jan 22, 2004 13:07:49 GMT -5
lol |
|
Ziggy
New Member
Ziggy the Hamster since 1-6-2001
Posts: 67
|
Post by Ziggy on Feb 25, 2004 2:08:27 GMT -5
Hey man, I do version numbers as dates.. It's more logical that way. And I start numbering all at 0.. 0 is "Pre-Alpha", 1 is Alpha, 2 is Beta, 3 is Stable Release and 4-9 are all "Minor Stable Builds". A full version number (1.x.x) denotes a fully working product, with minor version numbers meaning major updates, but same general style. Basically  br]0.1.0.20040225 The alpha copy, released February 25th, 2004. 1.3.0.20030101 The production copy, feature/major change 4 (remember, we start counting at 0), released Janruary 1st, 2003. This assumes you're on the same tree of source... If you branch off and start something totally different, you have to come up with a different system (perhaps the minor digit denoting the development status, and revision denoting the development progress). Example br] 1.2.3 = "Stable" Release 2, Beta, Revision 4 0.1.0 = "Stable" Release 1, Alpha, Revision 1 As for BeG.NET... it's not really .NET and the activation sucks ass. Suggestion, Alex: Instead of build numbers, use build dates. They're more accurate, and less annoying |
|
|
|
Post by Alexander on Feb 25, 2004 11:01:31 GMT -5
ziggy this projects been dumped , lol my new one has no activation and is much cooler |
|
