Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Goober5000 on January 26, 2010, 09:09:15 pm
-
It's that time of the blue moon again... the SCP is ramping up into Release Candidate phase. This means that 3.6.12* is just around the corner, and we need your help to ensure that it's as robust and bug-free as possible. During this time, Nightly Builds will be temporarily discontinued as we focus our efforts on the upcoming release.
We will shortly post a 3.6.12 Release Candidate for your evaluation. Please do your utmost to stress-test and bug-test this build as much as you can. Use it in your mods just as you would an "official" 3.6.12 build. We'll be depending on your feedback to catch any problems that may arise. There will be a Release Candidate category on Mantis specifically for bugs noticed during the RC stage.
Try to be as thorough as you can, because we'll only post a few (probably not more than three) RCs. Once we've released the official 3.6.12 build, you'll have to wait until the next official build cycle if you have a FSO itch that needs scratching. :)
* Yep, 3.6.12. We're designating 3.6.11 as the "interim" development stage, so 3.6.12 will be the upcoming official release.
-
You guys are amazing!
-
I've made this request to a few people but only on IRC, I figure I should probably throw it in here, but, could you please release the RCs as .11's since there was several .10s that were bouncing around that weren't 'final', I realise that's the point of the whole .11 nightlies thing, but since you didn't expressly say it, and I would prefer to see it clarified, could there only be one .12, for the sake of support/multiplayer compatability simplicity please? that one .12, being the 'final'?
Sorry if this has been communicated to you and is already your intention ;)
-
I'd still like to refer to them as 3.6.12 RCx. They won't be so vaguely identifiable as the last release, everywhere you can find version information will have a clear string denoting exactly what version you are working with including the RC designation. Calling them 3.6.11.999x might be an option though.
-
I tend to agree with QD on only having one 3.6.12. It makes things much easier from a support standpoint if we know that there is only one possible build with that number in the wild.
-
Agreed.
-
My 2 cents. Call them 3.6.12 RC but leave the internal version at 3.6.11. Will show in the logs if someone is running final or not right off the bat.
-
Agreed with FUBAR.
-
My 2 cents. Call them 3.6.12 RC but leave the internal version at 3.6.11. Will show in the logs if someone is running final or not right off the bat.
We often get support issues which could be fixed without the logs if we know the build involved. While your suggestion works I'd prefer to move away from requiring users to run the debug build and upload a log whenever we possibly can.
-
Leave version numbering to .11 until it is absolutely final.
-
My 2 cents. Call them 3.6.12 RC but leave the internal version at 3.6.11. Will show in the logs if someone is running final or not right off the bat.
We often get support issues which could be fixed without the logs if we know the build involved. While your suggestion works I'd prefer to move away from requiring users to run the debug build and upload a log whenever we possibly can.
The exec EXTERNAL filename can be _12_RC, right? Easily done. And the Revision # for the RC builds will be properly showing, so in the event some body RENAMES it, we'd STILL need the log and that version number will be useful for the SVN Revision number regardless of the Major/Minor?Whatever. Oh, and the same output that goes to the log? Shows in Pilot Selection screen and Mainhall as well, so instead of a log, we can say "What numbers are on your mainhall?" and done.
-
The exec EXTERNAL filename can be _12_RC, right? Easily done. And the Revision # for the RC builds will be properly showing, so in the event some body RENAMES it, we'd STILL need the log and that version number will be useful for the SVN Revision number regardless of the Major/Minor?Whatever. Oh, and the same output that goes to the log? Shows in Pilot Selection screen and Mainhall as well, so instead of a log, we can say "What numbers are on your mainhall?" and done.
I've got a test Xcode script which can update FS_VERSION_REVIS in the source (and thus the mainhall, log ....) from the latest SVN revision automatically before each build.
Is there anything similar which can automatically keep track with the latest SVN revision with Visual Studio?
-
I think you're missing my point. Many people will get the version number from the thread they downloaded the exe from or from the name of the executable. If the file is called fred2_open_3_6_12RC_r then when asked what number build they have lots of people just look at the filename. Can we not mention it being a 3.6.12 build there?
-
my 2 cents worth is to only have even numbers as "final" or "RC" so 3.6.11 would be the developement stage of 3.6.12 and so the next developement will be 3.6.13 which will create 3.6.14RC etc anyway ...;blah
-
At work we use a very long version identifier, as follows:
Major.Minor.Revision.Status.0.build
The Status section shows whether it's Alpha, Beta, RC or Released
Eg:
1.2.3.0.0.20 - Version 1.2.3 Alpha, build 20
1.2.3.1.0.35 - Version 1.2.3 Beta, build 35
1.2.3.8.0.74 - Version 1.2.3 Release Candidate, build 74
1.2.3.9.0.75 - Version 1.2.3 Released, build 75
The build number gets bumped continually by nightly builds, and is essentially equivalent to the SCP's svn Revision number
This is always shown in the About menu (or titlebar if there's no About)
We should do something similar that's always displayed in the mainhall/pilot, regardless of the actual executable filename.
A pretty obvious solution for the SCP is to display:
Beta:
Major.Minor.Decimal svnRevnumber
RC:
Major.Minor.Decimal RC svnRevnumber
Release:
Major.Minor.Decimal svnRevnumber
With odd Decimals being Alpha/Beta, and even Decimals being RC/Release.
The advantage of this is that the svn Revision number remains - and thus if we end up having to recall the Release we can tell if someone's still got the previous one.
(At work this has helped immensely when things have gone pearshaped)
-
Very Very convoluted system for general public support ;s
That's the exact opposite of what I was talking about heh :p
-
I'd be most happy if the one and only 3.6.12 was the official, final release. With 3.6.10, there have been many enough times when a person has said "I'm using 3.6.10" and you couldn't be sure of whether it's 3.6.10 Final, an RC, a nightly or one of those taylor's Xt builds from '08.
I mean, of course it is the SCP's decision, but it would be n times easier for tech supporters and n^2 times easier for the average users if there was only one 3.6.12 in existence.
-
Yep. I figured you and The_E would be the ones who really understood where I was coming from with this. :D
-
I agree with the statements here. We always said 3.6.11 would be the development builds, and RCs are technically still development status, so should be 3.6.11. The final released build should be 3.6.12 (and that should also be branched in SVN!)
-
RCs aren't technically development status though, like nightly builds anyway. They're candidates. Theoretically, an RC should be capable of simply being rebranded into final if it's stable enough. Personally, I think you guys underestimate people when it comes to these RCs, but that's just me. I know 3.6.10 was bad but I really don't think the RCs that will only be around a short time will get that prevalent, and they will be much more clearly marked regardless of how we number them. But if you want to insist that we keep them as 3.6.11s, defeating the purpose of the RC designation altogether, fine.
-
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
:p
But seriously, even though I don't do much direct support myself, I can completely see where karajorma is coming from. If you're talking about one of us regular forum members, of course we'll be able to tell the difference between a release candidate and a final build. But for the average Joe who happens to stumble across the SCP and downloads the most recent official-looking release, it's very likely that all they'll focus on is that "3_6_12" in the filename, and ignore whatever comes after. Hell, there's already enough trouble with getting people to recognize that 'd' stands for "debug," or getting them to post the error log with the right filename. Keeping everything as simple as possible, even regarding such a small detail as this, can save literally months of headaches for the few people around here who provide such excellent support on a daily basis. Making sure that there's only one release under the sun with "3.6.12" in the file name will probably help eliminate a big chunk of ambiguity.
And I don't really see how keeping the RCs labeled as "3.6.11" completely defeats the purpose of the designation. If you look at it a certain way, even though they're candidates for the final 3.6.12 release, as that release has not yet been achieved, they're still on the 3.6.11 side of the wall. Just phrase it as "3.6.11 candidates for the 3.6.12 release," or something along those lines.
-
I understand where karajorma's coming from, but I share chief's view that the Release Candidate builds should really be called 3.6.12 RCx. That's the way it's used in most projects anyway. We have RC1, maybe RC2, and RC3, and then 3.6.12 Final.
It's probably okay if we don't change the internal version number to 3.6.12 until the final release.
Karajorma, Jeff Vader, Mongoose etc. have a good point, I just prefer the way chief said it.
-
And how is this average joe going to get the assumption that the RC is the official release? When I find a software project and see Release Candidate, I am aware it's not the latest recommended stable. I might still try it though. But I'll keep in mind it's not the most recent one. The release period isn't going to be nearly as long as the period we were making 3.6.10 builds. They won't become so prevalent then. We won't start recommending the RC for daily use anywhere.
Take Mantis for example. They're at version 1.2.0 RC2 right now. I'm not a long time Mantis user or developer for them but I know what it means, and that hopefully in the near future I can expect a final or another RC build. They obviously trust their community not to make the mistakes we seem to be worried about with that either, even though their RC has been around for several months now. We won't make it painfully easy to get a RC build as we might for a stable build, although that's not terribly easy right now either. More of our problems come from our overall distribution method than whether we call it 3.6.11 or 3.6.12.
-
I suppose if RCs are not included in Turey's Installer, the less-than-bright users shouldn't mistake them for official builds. People who care less for the development side probably won't stumble upon RC release threads, since any written instructions shouldn't refer to them, but if Turey's Installer downloaded them, users might end up thinking they have the latest official build because "the official Installer downloaded it".
But yeah. As long as Turey's Installer doesn't download them and installation instructions don't refer to them, the RCs may as well be named 3.6.12 RCs.
-
Well one of the big issues is the packet breaking stuff for multi. You need to test RCs and you can't have people running 3.6.10 with the RCs so they need to grab the RC as well. Then if you have a second packet breaking fix for the final you end up with people running old RCs and not bothering to update to final as there was only one change. 3.6.10 RC 1 hung around for quite awhile with people crashing standalones all the time with it.
-
We committed our packet breaking fix already.
-
Yea saw it right before I posted that.
-
seems to me every time a final build rolls around, a critical bug (usually multiplayer related) is found and a new build is created to fix it. the result is multiple builds with the same version number. would be nice if the full version number was posted in plain sight in the lobby and the forming screen. that would probibly eliminate most of your multiplayer support issues.
-
Given that we should only have to do this once or twice because afterwards we'll have the launcher to auto-update I think it's worth it for the reduced hassle.
-
;-)
-
Unified shaders and post-processing, among other things. I think. Many random fixes too.
-
When you get around to posting RC1, I hope you will include a changelog of what's been changed since the last nightly, 5862.