Release Early, Release Often.

[imbaczek]

also, one lobby could be made to support multiple engine versions and hint (by graying out battles e.g.) which versions are available.

need rev number in unitsync though, a mere plus sign won't cut it.

[AF]

Can we make svn auto insert the revision number in a file somewhere say revision.h which we can then append in the code somewhere to the string 'spring' and a version string like '0.77b3' and use that as the version string?

[Warlord Zsinj]

I think it would make sense if new users by default had svn versions filtered out of their game list, and could turn this off through a checkbox option in the filters list.

[smoth]

that brings to mind another point. some files like OTAcontent.sdz may already be present but the installer installs them anyway. is there a way to make the update process a bit more streamlined to reduce server bandwidth hit and the amount of time the update takes?

[KaiserJ]

@ tobi : this is what i was thinking; you'd probably have one stable version of spring on which all of the current mods work, and then a WIP version that would be the one in development; as long as you regulated version releases so that only the devs would be allowed to add a "new" version.

@ masure : i expect you would get SOME people clinging to older versions of spring, possibly because of compatibility issues and wanting to play mods that are no longer supported on the newer versions; but i have a feeling it would be more like having an accepted spring version for each game rather than having the battle list be a big mix of different versions (so that if there was a popular mod that was no longer in production and didn't work with newer versions of spring, you would still have the opportunity to play.) beyond that, i saw lots of people in #main talking about errors and stuff and getting really frustrated because they wanted to play a game but weren't able to, so i think it's a good idea if old versions are supported.

this isn't to say that each mod or game should be tied to a different spring version, ideally every one will run on the newest release; but there's always going to be a gap in time between when a spring version is released and when each mod works properly on it without bugs (i assume) even if it's only for a day or two.

edit : warlord, very good idea

[Licho]

If you keep changes isolated to say spring executable, we could allow multiple engine versions even now easilly..

For example game name could contain special [svn<rev>] tag is there is desire to play given version, lobby would then start another executable (possibly asking SD to download it or even keeping whole job of picking corrent executable up to SD).
In fact I could completely hack around lobby with SD to provide multiple engines (it would rename itself to spring.exe and run correct executable based on version, it would detect version by querying downloader server with IP of the game host to get game name and svn tag from that name.)

But it would be best to simply add engine version to battle information and built-in lobby support :)

[Forboding Angel]

Read everything /pant

+1 to all the devs+argh+licho and most notably, Tobi.

Tobi, remember when you set up scheduled testing for .77b1? That would out really really well, and I would be happy to help test. At that particular time it helped me out quite a bit to, can EvoRTS was kinda starting to become on the verge of fruition at that time, but iirc we played Gundam, BA, EvoRTS, CA, and various others, and as I remember it, we had a pretty darn good time with it. It would be nice to see that sort of thing come back.

[Wisse]

I (and many others for sure) would be happy to test new builds and report bugs if there was an option to run both releases (stable and test) from lobby. Test release could get autoupdated once per week or so.

You guys could than plan stable release which would mean that our test version doesn't get updated for 2 weeks or so, giving us time to report last bugs and you to iron them out.
We should even get "bug report" form up in lobby after each game that ends/closes/crashes using test version.

You should never use whole community as test subjects tho. This community is so small (which makes it fragile also) that you just can't risk on turning off players which don't want to mess with painful version transitions.

But I'm not willing to play on completely different server for the sake of testing couse it's hard to get games even with whole (!) spring community together.
I can't be bothered to manually update game also. Maybe if it's possible for me to get things updated using SVN.


I'm no programmer, but it feels to me that if you pulled together and sacrifice some of ur precious time on making those changes you all agreed on would save shitloads of time in the future. Plus we would probably get alot more polished released which means that they won't be painful for newbies to use.

[imbaczek]

autoupdater is basically done thanks to Licho's springdownloader, needs another module and voila. The problem is in the server.

[AF]

A few days after 0.77b4 is released, if no major bugs pop up we should send an html email out to everyone on the forums advertising the new release to draw some old users back in

[el_matarife]

A few days after 0.77b4 is released, if no major bugs pop up we should send an html email out to everyone on the forums advertising the new release to draw some old users back in

This may annoy people more than it draws people back. I'm not sure mass email blasts are the way to get old users back, as much as asking everyone to go out and tell all their friends that the new patch is out and they should come back to try it.

[AF]

The glest community do it to great effect. Eitherway its worth doing the once as an experiment. Old users who get annoyed will either come back and say they dont like it or not bother coming back just like they would if they hadn't received the email. or it could work

[el_matarife]

I'm just concerned about the Spring domain being added to spam blacklists or something like that. Also, you should probably only send it to people who "opted in" to receive messaged from forum administrators.

[panzeriv2]

I'm here to say something (LOL):

DON'T RELEASE OFTEN!
Today, I just came back from you-know-where wanting to play Spring and whatdya know, a new Spring version is out! WTH DO YOU MEAN THAT I NEED TO GET THE NEW VERSION!!?? Fine, it is okay with releasing early, but releasing bugfixes ONCE every week is DUMB!

(Not spring related, but I'll tell)
What's more, jeez, I need admin access to install this .77b4 update, which means I need to wait 6 more hours to play Spring!

Okay, fine, I agree for my unnecessary rage here but NEW VERSIONS EVERY NOW OR THEN IS DUMB!! Why don't you release patches instead of 14mb installers-that-can-go-wrong? Patching without the need for admin's permissions is even better.

Or, could you stop forcing people to use the latest version to play online? What people want democracy, not dictatorship!

I hope 0.77b4 will be the last in the .77 series. Hopefully, what I want to see in the next release is .78

[panzeriv2]

I'm just concerned about the Spring domain being added to spam blacklists or something like that. Also, you should probably only send it to people who "opted in" to receive messaged from forum administrators.

Agree.

[AF]

With the opt-in that's sort of implied by my idea already

[Wisse]

I'm here to say something (LOL):

DON'T RELEASE OFTEN!
Today, I just came back from you-know-where wanting to play Spring and whatdya know, a new Spring version is out! WTH DO YOU MEAN THAT I NEED TO GET THE NEW VERSION!!?? Fine, it is okay with releasing early, but releasing bugfixes ONCE every week is DUMB!

(Not spring related, but I'll tell)
What's more, jeez, I need admin access to install this .77b4 update, which means I need to wait 6 more hours to play Spring!

Okay, fine, I agree for my unnecessary rage here but NEW VERSIONS EVERY NOW OR THEN IS DUMB!! Why don't you release patches instead of 14mb installers-that-can-go-wrong? Patching without the need for admin's permissions is even better.

Or, could you stop forcing people to use the latest version to play online? What people want democracy, not dictatorship!

I hope 0.77b4 will be the last in the .77 series. Hopefully, what I want to see in the next release is .78

If they implement features suggested in previous posts they will be able to release test versions often and stable one just few times per year. That would make it possible to get proper stable releases out without bugs and need for updating in next few months which should be better for players like you.

But than again I'm not rly sure if devs will come together and make something like that possible. With complete support (SpringLobby, TASClient including) of course.

Ppl should be forced to use latest !Stable! version, because community is just not big enough to split it even more. But first something has to be done to get more testers.

[AF]

That we're all together under the spring banner and only the spring banner at all contributes massively towards keeping our community small.

We have all our eggs in one basket, obviously the basket can only hold so much before they start falling out and cracking.

[Wisse]

Time to make get bigger basket than, or even better make sure there's some padding around basket for those eggs who only wanna play spring, not deal with it for quite large amount of time.

No rly, i haven't heard better proposal about improving spring in my time lurking around forums than this one is. Testing should follow CA model but with alot larger time scale. Because than we could get user friendly, bugless releases which means alot less users dropping in first few days after installing and/or updating spring.

Than we only need community binding features like server supported clans n shit and we've got ourselves user friendly community supporting engine which would be much more fun to use and less painful to cope with.

But don't say "Do it" to me. I'm willing to test but I do not know how to code and don't have time to learn it!

[AF]

I think before we put forward the prospect of multiple engien versions installed using the same lobby environment we need a little 'refactoring' of sorts.

Firstly:

• Move the engine and its dependencies into a dedicated bin folder
• Build a version of the installer script that does not add shortcuts and registry entries or download content such as BA/maps etc and could be installed to a folder with little or no impact, aka its intended to be installed alongside or inside an existing spring install and managed by the lobby. Just the core of the engine itself. This would have other uses as well.
• rename spring.exe to engine.exe or spring-engine.exe
• The engine binaries should be stored at /bin/077b5/spring-engine.exe and a lua file pointing to the default/preferred folder. This would prevent re-downloading of the previous version unnecessarily by lobbies, and it would also be more flexible. An added advantage is that lobby involvement is no longer needed to manage the system, not that lobbies cant improve upon this.
• Sub folders in the above mentioned folder can be used on top of that for sdz/sd7 archives and other files that should only be loaded for that version, aka they're version specific.
• The above mechanism should have Unitsync APIs for polling which versions of the spring engine are available, as well as a means for content developers to specify a minimum and a recommended version, aswell as an optional maximum version. This would also be done for maps.

This gives us a clear defined method of keeping multiple versions of the spring engine. It cleans up the root folder of spring and allows maximum flexibility.

Simply moving spring.exe in a sub folder and adding a version number then swapping the core executable out when needed is a hackish way of doing things and it is not safe either due to differing dependencies and APIs. This method allows maximum compatibility.


Minor modifications to the VFS will be required, as well as the installer scripts, nothing that couldn't be done in a days time if we all worked on it.