[Goober5000]

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.

[origin]

You guys are amazing!

[QuantumDelta]

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

[chief1983]

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.

[karajorma]

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.

[Zacam]

Agreed.

[FUBAR-BDHR]

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.  

[The E]

Agreed with FUBAR.

[karajorma]

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.

[Fury]

Leave version numbering to .11 until it is absolutely final.

[Zacam]

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.

[Echelon9]

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?

[karajorma]

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?

[captain-custard]

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

[Tomo]

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)

[QuantumDelta]

Very Very convoluted system for general public support ;s
That's the exact opposite of what I was talking about heh 

[Jeff Vader]

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.

[karajorma]

Yep. I figured you and The_E would be the ones who really understood where I was coming from with this.

[portej05]

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!)

[chief1983]

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.