Unstable releases?

[Radtoo]

Would you guys consider just spelling out a revision number bi-weekly or monthly or so, as current "unstable release"?

I think it would be very easy to do, and help in many ways.

I'd also like to make a case for NO testing for the unstable release beyond a buildbot pass. You really shouldn't have to actually worry about it directly, but it would help down the stream, from testing to distributors to people who actually have problems that were fixed...

[imbaczek]

that's hard to do in spring, since most of those releases would desync with each other. if you want to test, there are buildbot builds, and - an added bonus - they happen much more often than every two weeks.

there used to be some coordinated testing events which resulted in moderate success, but it takes a lot of time to organize them. one idea I had is to hold tournaments using a set svn build, but, as usual, this needs time and players.

[bibim]

I think we could automatize some tests... An autoupdating SVN autohost is already running on the lobby server, so it would "just" require some "autoclients" that would synchronize their SVN revision with the autohost one, launch some AIs, and report any error. Of course this wouldn't check for graphic corruptions or such things, but it could detect desyncs or crashes...

[KDR_11k]

A problem is that AIs crash a lot more than Spring so it's hard to see when you've got a genuine crash.

[smoth]

AFAIK luaAI doesn't cause crashes... so things like the chickens might be useful in testing for stability?

[Radtoo]

that's hard to do in spring, since most of those releases would desync with each other.

Wouldn't testers have the same release for about two weeks?

there used to be some coordinated testing events which resulted in moderate success, but it takes a lot of time to organize them. one idea I had is to hold tournaments using a set svn build, but, as usual, this needs time and players.

I almost conclude this means "yes" to my last question... and it is what I thought would be nice to get. A revision number every few weeks...

if you want to test, there are buildbot builds, and - an added bonus - they happen much more often than every two weeks.

I've got svn AND git ebuilds for both spring and springlobby (one of which would be your gitorious mirror - svn rebase please? :p). It's not really the issue at hand though.

Every revision or daily is very good to have but in general too rapid for all non-developer people. That also includes bug testers.

[imbaczek]

Radtoo: I kinda agree with everything you say, but all of this needs work (duh) and the whole spring devteam is pretty much always short on time.

IOW - if you want to coordinate some testing, installers are there, it's just a matter of blessing a revision number every two weeks and telling people about it - the hard part is getting them to listen.

[AF]

tbh this whole thing can be solved with a technical fix rather than an organisational fix.

The technical fix would also correct a few issues regarding how the spring directory is interpreted.

• Move all the dll and executables into a bin subfolder
• Create sub folders for specific revisions of the engine so /bin/0.77/ /bin/0.78/ and so on and put shared binaries (probably libraries) in /bin/shared/
• rename spring.exe to engine.exe
• Add an engine revision parameter to the lobby protocol, along with an engine name parameter which defaults to "spring".

This way if a player hosts an experimental spring only experimental spring players can join, but they can still join normal games if they have the necessary binaries installed.

[LordMatt]

I think Satirik has also talked about doing that.

[Satirik]

i didn't and it's not a bad idea but it would need to update the server ...

edit: what i did is putting old release of spring in one dir to let people watch old replays

[aegis]

but it would need updating of the server. just tell me these things

[Argh]

+1, to AF's suggestions, it would make it a lot easier to start playtesting new SVN-only stuff, and start seeing where the problems are.

[Radtoo]

All of these things are not the same.

• The server side fix to support more versions of spring:
  
  Yep, that's highly desirable in any scenario. Right now, every time the engine is updated and some mods / platforms aren't, its an unhappy time. I was told this would be a little bit of work, though... :)
• The client side:
  
  Spring.exe -> engine.exe: Don't. It could be spring-0.93.exe. Or spring-2939.exe. That way its halfway comfortable to use on all *nix and even the windows console.
  
  You'll also have to librar'ize & API-version almost everything and share these files, otherwise that will cause extreme bloat and redundancy. Looks like a large task to do right to me, overall.
• Unstable releases:
  
  They're not taken care of by just being able to install any SVN revision. You actually want a predictable and not quite as frequent "everyone-tests-the-same-on-all-platforms" type of release for the least amount of chaos and incomparability of results, workarounds, fixes and so on.
  
  Almost everyone (but the developers) will do better on these, and its not mutually exclusive with re-verifying confirmed problems against the very latest svn. This is trivial to do.

[AF]

spring-engine<version>.exe then. The reason I said engine.exe and not spring.exe was because when spring is installed and the user goes to the spring folder they see spring.exe and expect a full GUI itnerface with menus and options and singleplayer, its totally counter intuitive when they realize that is not what they're getting.

Which is even worse because the options they should be clicking on look nothing like what they expect. Aside from the 'tasclient.exe' and the tasclient link in the start menu, people think spring IS tasclient and its totally confusing.

[Radtoo]

@AF: Ah, that makes sense.

@Aegis: I hadn't realized you took over the server development prior to seeing the front page announcement...

Would it be much work to do the multi-version support tasks, such as list games by version, and perhaps to allow people change engine version / map / mod after creating a game or to exchange their supported engine versions / maps / mods prior to starting a game?