0.79 releases

[SirMaverick]

There were 3 versions released: 0.79.0, 0.79.0.1 and 0.79.0.2.

The Lobby accepts all 3 when connection to it. When there are players with different versions in one game it might cause desyncs - this is known.

It's better to force them all to use one version (even if they have to install spring twice or more within a short time period). Otherwise they install any new version and desync/crash. "Oh new released spring is even more buggy" - no good publicity.

Don't give them a choice, force them. It's better for all.

[imbaczek]

+1 but needs a version bump in the engine.

[Beherith]

+1
force them all to use one version

[lurker]

I was thinking that could wait until we're sure we have a solid version. We still have the issues with certain graphics cards and text being slow because of the size of iforgot, that needs to be a config var. And when we do bump it won't be necessary to kick everyone off the server.

[Licho]

+1

imo release versions as fast as possible...

Every 1 week new engine version if needed.

Progress will be faster, bugs wont accumulate so hard and increased feedback will make more people willing to work on engine.

I dont see any reason to delay engine release if its reasonably automated/easy to make the release.

[zwzsg]

What about people like me or Argh that do custom installers?

[Argh]

I'm entirely OK as soon as our own official server's up, which is going to be soon.

[Gota]

Men WTF?
since when do projects make weekly releases?or even monthly?
This way the engine will always be in transition,for the obvious reason that this engine will never be considered complete .
Its better to have a small period of shit breaking up than having to update all the time little by little and having shit breaking all the time..
Not all projects have 10 devs working to wipe every little turd that pops out.
With faster releases you will destroy smaller mods.

If there was some finite goal that we needed to hurry to than sure but there isn't

[Licho]

Is it better to have perdiods of things breaking up lasting weeks to months or NONE periods at all??

If there is steady bugfixing and constant fixing bugs wont accumulate.

And all those annoying little things that players mod developers have to live with will be fixed/improved faster.

CA updates daily and you rarely see test version broken for any significant time even with devs who commit versions withotu checking them in game :)

Identifiying and locating bugs will be much much faster and easier with small incremental changes than with ZOMGHUGE commits and releases.

[Licho]

Besides, games can of course opt to run on older version of engine..

[Pxtl]

Men WTF?
since when do projects make weekly releases?or even monthly?
This way the engine will always be in transition,for the obvious reason that this engine will never be considered complete .
Its better to have a small period of shit breaking up than having to update all the time little by little and having shit breaking all the time..
Not all projects have 10 devs working to wipe every little turd that pops out.
With faster releases you will destroy smaller mods.

If there was some finite goal that we needed to hurry to than sure but there isn't

Actually, lots of projects do weekly releases. In fact, many projects have nightly builds available, if they have an auto-release process. CA is a good template to look at - many OSS projects follow that approach.

The difference is that said projects usually have a "stable" release and an "unstable" stream (like CA).

[Gota]

Well i speak for most of the community when i say no to CA style release schedule.

[thesleepless]

keep a stable lobby so people who actually want to play a stable game can play.
have a test lobby, if people are running a newer version than stable they connect to the test lobby and can play games against people with the same version as them.
once the test is stable then make that the new stable. but don't kick people with the old version off, just make it so they can only play games against the old version, and tell them they should update.

[Tobi]

I agree with release early release often.

But as pointed out there are some major issues holding this back:

• Custom installers. All of them need to be rebuilt on every engine release. (Well you could just ship an old Spring and have people forced to update just after install.. but we all know updates don't always go as smoothly as they should...)
• Lobby server. It does not support keeping track of multiple Spring versions. Either it checks the version or it doesn't. In the first case only a single Spring version can be used on the server, in the second case a big chaos would result because everyone can use any Spring version and there's no way to see which version one is using.
• Breaking upgrades of APIs, e.g. unitsync, startscript. Sometimes these are needed and always they disrupt any regular (semi-automatic) release process. IOW, doing Spring as CA or wesnoth is much easier said then done. As far as I know, both CA and wesnoth don't consist of many independently developed systems that all need to be at the right version to work together.

Hence

Besides, games can of course opt to run on older version of engine..

this is not feasible atm, unless the game sets up it's own lobby server.

Suppose it's time to start working on TASServer again.

Stable/unstable sounds interesting but I doubt a bit how many people would use unstable. It is exactly what I tried to set up long ago (I updated test server every week to new buildbot-built spring version for a while), but as I said in other thread unstable was usually only played when I dragged people in. Maybe the time is better for it now though, will see what I can do (but probably won't have time very soon for yet another project..)

[el_matarife]

What about a schedule that's rapid but not too rapid? For instance, a release every two months or every three months? I don't know how much work is involved in updating the custom installers, but I hope having to update once every 3 months wouldn't be too much work? Also, what about making a "template" build of a custom installer on GIT where all the work required would be swapping the pictures and a few strings like installer name?

[koshi]

Also, what about making a "template" build of a custom installer on GIT where all the work required would be swapping the pictures and a few strings like installer name?

git clone git://springlobby.info/git/koshi/installer
not updated for 0.79 yet, also includes buntu package example from s44

[Acidd_UK]

Well i speak for most of the community when i say no to CA style release schedule.

I hope you don't speak for most of the community.

I dont see any reason to delay engine release if its reasonably automated/easy to make the release.

That's the key - automating the release so the user doesn't need to have any input.

[Licho]

There are 2 ways:

1) just force update on everyone. Mods who really want to use custominstaller can pack older version and connect to different server running older spring version. If its case of S44 this hides other mods anyway so its ideal solution.

2) support multiple engine versions finally.
Even with some very strict limitations - like changes restricted just to executable, so its easier to maintain/update it and can run from same unitsync.

[Tobi]

1) is not ideal at all, it would mean everyone who plays more then only S44 would have to keep multiple lobby clients open.

2) is the only solution, but of course hasn't been done yet cause TASServer is unmaintained and uberserver just doesn't work or something. (I bet aegis will now come and post here that it does work, but then I wonder why he hasn't deployed it yet.)

[Auswaschbar]

(I bet aegis will now come and post here that it does work, but then I wonder why he hasn't deployed it yet.)

Aren't you the one who employs / not employs it?