Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Nightly Builds => Topic started by: SirKnightly on February 02, 2013, 10:06:56 am
-
Here is the nightly for Windows on 02 Feb 2013 - Revision 9520
Group: Inferno
fso-WIN-Inferno-20130202_r9520.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20130202_r9520.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno-20130202_r9520.md5)
Group: Inferno_SSE
fso-WIN-Inferno_SSE-20130202_r9520.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20130202_r9520.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE-20130202_r9520.md5)
Group: Inferno_SSE2
fso-WIN-Inferno_SSE2-20130202_r9520.7z (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20130202_r9520.7z)
MD5Sum (http://swc.fs2downloads.com/builds/WIN/fso-WIN-Inferno_SSE2-20130202_r9520.md5)
------------------------------------------------------------------------
r9520 | karajorma | 2013-02-01 23:19:04 -0600 (Fri, 01 Feb 2013) | 1 line
Changed paths:
M /trunk/fs2_open/code/ai/aicode.cpp
M /trunk/fs2_open/code/network/multimsgs.cpp
M /trunk/fs2_open/code/playerman/managepilot.cpp
FUBAR's fix for Mantis 2778 (Game_skill_level goes out of range and causes crashes) with some changes by me.
------------------------------------------------------------------------
-
Since 3.6.16 has been released, shouldn't this be 3.6.17?
-
Yeah we do need to get the versions bumped in trunk but we're doing that when the antipodes stuff gets merged in.
-
That does raise the question of what we bump it to. :p
3.7 is meant to be the next release so that's out.....
-
3.6.99 would be my suggestion.
-
3.6.99 would be my suggestion.
sounds good to me
-
I was thinking more like 3.6.17, or use 3.7 for trunk and the next release be 3.8.
-
3.7 certainly has the advantage of being able to drop the least necessary digit. I guess I'm just not that hot about another round of "What used to be called 3.7 is now 3.8".
-
Personally, I've never been concerned with trying to match feature X to version Y. I think we should just be calling it what makes the most sense, and to me that involves dropping some digits and still training to maintain our odd-development/even-stable setup.
-
Maybe let's call this 3.6.17, then switch the nightlies to 3.7 when Antipodes 8 goes into trunk and finally release the thing as 3.8.
-
Nevertheless it's quite fun to watch these numbers go up so suddenly and joyously, with the added benefit of being actually filled with new content! You guys are the best! :)
-
We've always said that 3.7.0 will be the new pilot code and we should keep it that way. I don't see any reason why that would prohibit using 3.6.17 as the interim version number.
(It would also allow us to release another build on that branch in the highly unlikely scenario of SCP maintaining parallel development on 3.6 and 3.7.)
-
We always said a lot of things that have changed. We always said 3.7 would be after 3.6.14. I frankly don't care that we should do it just because it was 'always said'. There's also a lot of bugs in Mantis that were at one point slated for FSO 4. And, as I suggested, 3.7 _would_ be the pilot code, just only for trunk/nightly builds. 3.8 would be the stable designation.
-
I think the odd/even rule works fine for the third digits place, but at least to me, applying it to the really big "main" releases would just invite confusion. You'd have a bunch of people asking, "Wait...did I miss 3.7 somewhere? Why is 3.8 the newest release?" I think most people who use software that updates fairly frequently, like Minecraft for instance, are used to seeing that decimal point increment normally, so sticking with that convention seems like a prudent way to go.
-
Every release has been a fairly big release. This one is going to be bigger than some, but we're trying to permanently drop a digit I think, instead of continuing with 3.7.2, 3.7.4, etc. Unless everyone wants to keep the triple decimal setup. I thought most were getting tired of it.
-
What about using the dual digit as a marker for stable releases (i. e. 3.7, followed by 3.8, 3.9 etc), while using triple digits (3.6.xxxx, where xxxx is svn revision) for nightlies and other dev builds?
-
"FSO 4" is just a placeholder tag for things that could potentially be implemented but won't be implemented in the foreseeable future. It's sort of a joke tag that represents the asymptotic conclusion of the infinite 3.x.y series, but it serves a useful purpose as a tag to let people search for those issues. I know that at least one "FSO 4" issue has actually been solved.
As for versioning, we certainly do not want to jump to 3.8 immediately after reaching 3.7. We need to spend sufficient time on 3.7 that 3.8 would represent a major milestone. If we are running into a problem due to the need to keep release builds and testing builds distinct, then one solution would be to use 3.7.1 for the development and 3.7.2 for the release. Using 3.6.99 would also work, as was suggested earlier.
And we should keep the triple digit numbering scheme. People weren't getting tired of that so much as getting tired of the fact that it took so long to reach 3.7. The numbering scheme is, and has always been, 3.x.y.zzzz, where the first number is always 3 (for FreeSpace 3), x is the major version, y is the minor version, and z is the SVN revision. The only reason for dropping a digit is when using an informal reference, such as the 3.6 line vs. the 3.7 line. When we release 3.7, the internal version will actually be 3.7.0.zzzz.
-
We haven't automated that for nightlies and other dev builds yet, and I'd still prefer that stable releases have a number all to themselves, not just only short of a revision number. I thought that was one thing that was helping out the support guys tell builds apart, having no ambiguity between a stable release and a random development build.
-
At work we use Major.Minor.Patch.State.Build
"State" is a number from 0 to 8 for anything that's "in development", and "9" once it's released.
So, for example the beta "1.0.0.1.4242" will become "1.0.0.9.4242" if it's turned gold.
It makes it really easy for support to know whether the version someone's running it's actually a release (State==9), alpha (State==0) or at some stage of beta (0<State<9).
Perhaps the SCP could do something similar?
Start with 3.7.0.0.95xx, and work up to 3.7.0.9.zzzz?
-
I'd still prefer that stable releases have a number all to themselves, not just only short of a revision number. I thought that was one thing that was helping out the support guys tell builds apart, having no ambiguity between a stable release and a random development build.
I agree, and I don't think that anything I wrote contradicts this.
-
Nope, I was replying to the post before yours before you posted yours.
-
At work we use Major.Minor.Patch.State.Build
...
Perhaps the SCP could do something similar?
SCP does something very similar. To use your notation, we say 3.Major.Minor.Build.
-
At work we use Major.Minor.Patch.State.Build
...
Perhaps the SCP could do something similar?
SCP does something very similar. To use your notation, we say 3.Major.Minor.Build.
Indeed - I'm suggesting inserting a "Status" in between Minor and Build/Revision.
Status could be "0" for "Nightly Build", then 1 thru 8 for RCs and finally 9 on the frabjous day.
-
That scares me a little, people already find the terminology a little intimidating. If a number changes it should be the last number in the string so people always know to grab the one with the biggest number!
-
Batty, it still leads to a bigger number overall...
-
As long as you're not including the revision number on the end, yeah, but I just want to avoid situations where people get hung up on a long string of digits and their eyes glaze over. People are very prone to transposing and dropping digits in strings, so the more values in the string the more dangerous it is - people start swapping their 3.6.16.9s with their 3.6.9s and dumb stuff like that.
-
I would agree that 3 significant numbers is quite enough for us. Anything more, and it gets rather silly.
-
I think I'd prefer not to use 3.6.17, as that's already used in the BP builds and it'd be nice to have the fs2_open.log clearly distinguish between pre-3.7.0 and BP.
-
Isn't that because it was already committed to antipodes that way? :p
-
Yes, antipodes is currently 3.6.17 (forgot about that :D)