Versioning
Moderator: Developers
RE: Versioning
I'd suggest Major(number).Minor(number).Bugfix/emergency(letter, if needed, default to "a")
You always know with just a look which version is newer this way, and it's pretty nice to look at too.
Ex.: 1.0 - 2.1a - 1.8c ...
It also allows for easy data transactions as it's just 3 bytes.
You always know with just a look which version is newer this way, and it's pretty nice to look at too.
Ex.: 1.0 - 2.1a - 1.8c ...
It also allows for easy data transactions as it's just 3 bytes.
Last edited by DocCobra on Mon Jul 09, 2012 1:20 pm, edited 1 time in total.
RE: Versioning
1.0 Alpha -> 1.0 Beta -> 1.0RC -> 1.0RTM
1.1 -> 1.2 -> 1.2.1 --------------->
1.1 -> 1.2 -> 1.2.1 --------------->
-
- Zandrone
- Posts: 1244
- Joined: Thu Jun 28, 2012 9:07 pm
- Location: Rwanda
RE: Versioning
Isn't the Huffman coding for Skulltag very "non-optimized"? Would this be something that could be fixed in Zandronum if its true?
Also for version numbering:
1.0 -> 1.1 -> 1.1a... -> 2.0 -> 2.1 ... 666.0
Also for version numbering:
1.0 -> 1.1 -> 1.1a... -> 2.0 -> 2.1 ... 666.0
Last edited by Watermelon on Fri Aug 17, 2012 4:36 am, edited 1 time in total.
RE: Versioning
I was thinking 1.666 but ehWatermelon wrote: Also for version numbering:
1.0 -> 1.1 -> 1.1a... -> 2.0 -> 2.1 ... 666.0
RE: Versioning
How about the Google/Mozilla solution of just ++1 every new version?
A version number doesn't really do anything other then keeping a clear distinction between the versions that are old, stable and beta. There is no reason to complicate this with decimals. We could make an exception for beta's as those come out a lot more often, but stables should just follow the ++1 versioning.
A version number doesn't really do anything other then keeping a clear distinction between the versions that are old, stable and beta. There is no reason to complicate this with decimals. We could make an exception for beta's as those come out a lot more often, but stables should just follow the ++1 versioning.
-
- Forum Regular
- Posts: 470
- Joined: Mon Jun 04, 2012 9:41 pm
- Location: Mexico! aka the hell gate
RE: Versioning
use whatever, just upgrade Zandronum! (the idea of docCobra is good)
Last edited by katZune on Wed Sep 05, 2012 2:28 am, edited 1 time in total.
Whitout a good PC ATM, i will back when 2.0 come out, :)
Spoiler: The True (Open)
-
- Forum Regular
- Posts: 294
- Joined: Sat Jun 16, 2012 7:42 pm
RE: Versioning
I'm up for anything as long as it includes an easily recognized version name, as in there's a big difference between Zandronum 1.0 and 1.2, not so much Zandronum RC1, RC2. Of course, this is personal opinion and I don't like "RC"
RE: Versioning
In order to look different from ZDoom's method, how about instead of ##.##.##, go with ##.##x, where x is a letter similar to what you were using in Skulltag? So, the sequence would be 1.00, 1.00a, 1.00b ... 1.01, 1.01a, 1.01b ... 1.02, 1.02a ... ... 2.01, 2.01a etc. It would up to the devs to decide when to increase the letter, when to increase the number after the decimal, and when to increase the number before the decimal. This would be every bit as flexible as ZDoom's method, but it would be different enough to not be confused with a ZDoom version number.
Never mind that. I just realized that looks just like ZDaemon's method.
Here's another idea. Use the form ##.##x## where the ##.## at the beginning would match the version of ZDoom that is currently being used as the base, x is a letter, and then then another 2-digit number. Starting after the already-released-and-named Zandronum 1.0, assuming you base the next version on ZDoom 2.50, and then don't update the base again until ZDoom 3.20 (just to give me numbers to use in my example), the sequence would be 2.50a01, 2.50a02 ... 2.50b01 ... 2.50c01 ... ... 3.20a01 etc. This would have the advantage of making it clear upon what version of ZDoom is the current version of Zandronum based.
Oh, here's yet another idea. Drop the decimal, and continue Skulltag's method. After 1.0, the resulting sequence would be 100a, 100b, 100c ... 101a, 101b ... 102a etc, with no limit on how high the number can eventually go. You could even occasionally skip to the next 10 or 100 for really major releases, like 106e followed by 110a, or 177d followed by 200a. Of all these ideas, I like this one best.
Never mind that. I just realized that looks just like ZDaemon's method.
Here's another idea. Use the form ##.##x## where the ##.## at the beginning would match the version of ZDoom that is currently being used as the base, x is a letter, and then then another 2-digit number. Starting after the already-released-and-named Zandronum 1.0, assuming you base the next version on ZDoom 2.50, and then don't update the base again until ZDoom 3.20 (just to give me numbers to use in my example), the sequence would be 2.50a01, 2.50a02 ... 2.50b01 ... 2.50c01 ... ... 3.20a01 etc. This would have the advantage of making it clear upon what version of ZDoom is the current version of Zandronum based.
Oh, here's yet another idea. Drop the decimal, and continue Skulltag's method. After 1.0, the resulting sequence would be 100a, 100b, 100c ... 101a, 101b ... 102a etc, with no limit on how high the number can eventually go. You could even occasionally skip to the next 10 or 100 for really major releases, like 106e followed by 110a, or 177d followed by 200a. Of all these ideas, I like this one best.
Last edited by Empyre on Thu Sep 06, 2012 8:33 am, edited 1 time in total.
"For the world is hollow, and I have touched the sky."