0.79 releases

[Pxtl]

I have a question: how hard would it be to do a regex search for any case of the word Spring occurring in quotes in the Engine, SpringLobby, SpringSettings, Installer (ArchiveMover is a problem, since files are impossible to distinguish), and replace it with a precompiler-macro ENGINENAME

Then have an Unstable and Release build, where ENGINENAME is "Spring" in release, and "Spring Unstable" in unstable.

So files get installed into Program Files\Spring Unstable, the executable is called Spring Unstable.exe, the registry key is Spring Unstable, and so on.

Would such an approach work?

[Auswaschbar]

How does that solve the problem of the server not supporting multiple versions?

[Tobi]

(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?

In the end yes, but I made aegis "lobby server man" at some point in time and said to choose for himself when to deploy.

Then we tried to deploy uberserver one time but I had to restore TASServer myself cause it was stuck in LAN mode for a week already with not yet any ETA on a fixed uberserver.

Anyway, I think I'm going to fix the design issues in TASServer ASAP.

[Auswaschbar]

Or maybe we should give uberserver another try? I mean, what software is [del]perfect[/del] actually works on the first release?

[djmad]

split the releases a little bit more

everything which has nothing todo with network-sync can be installed if people want it, everything whats sync.critical must be installed

also a autoupdater would be nice, which only leeches the parts which are needed.

like 0.79 1
like 0.79 1 bugfix 1
like 0.79 1 bugfix 2

everytime sync related a new v number
0.79 2

is a autoupdate per svn possible to update the sources?? so only new parts have to be recompiled??

greets djmad

[Pxtl]

How does that solve the problem of the server not supporting multiple versions?

You use 2 masterservers - one for unstable, one for stable.

The idea is to have two _complete_ installations of Spring. Imho, that's why nobody tests - their two installations tend to step on each other's toes.

[zerver]

Imho, that's why nobody tests - their two installations tend to step on each other's toes.

I agree 100%. This way you can also see if the new version was a success or not. If noone plays the new, the old was better.

[imbaczek]

having a single install for both testing and stable spring is infeasible, with base file updates, etc.

[Licho]

Are base file updates really that often?

I thought that vast majority of changes have effect on just the executable..

In such case lobby can maintain multiple exe and fetch new one on demand..

In the simplest scheme it needs just 2 exe - stable and test. And it can rsync test.

When there is need for base file update, full update can be triggered knowing it wont break anything, because test had been tested enough.

You dont even need lobby server update, it can be hacked into game name or whatever. You only need lobby support which should be easy to get.

[Auswaschbar]

Who is going to make those plenty of debs, rmps, tarballs etc. every week?

[zwzsg]

Every 1 week new engine version

Please NO!

CA would be the only mod to survive under such conditions!

The CA model only work for CA and for nothing else. CA is the only mod that has like thirty active constributors and daily releases. The only other mods with a team behind are S44 and SWS, which do like yearly releases in average. And every other mods are 1 man work. Yes, even complete TC such as Gundam, EE, or Pure are largely one man work. Even if BA changed maintener, it's still only one person at a time.

Content and engine bugs are more interwined that you'd assume. Every time there's a new Spring release, some mods get broken, in very varied and creative ways. It could still work out if engine devs cared about mod and retro-compatibility, but that concept has been lost as the original Swedish Yankspankers left. Nowaday, modders are just told to suck it up, then laughed at because they aren't as quick to catch up as CA.

One day gl.GetTextWidth is 25% smaller than the previous day. Suddendly armor.txt becomes compulsory. Overnight script piece names becomes case sensitive. Out-of-the-blue arguments in SetShieldState are swapped. Some keywords get theirs _ replaced by a . because it's prettier. Certain textures gets the role of two channels swapped just because. That cool command that was added ten version ago? Oh it's just gone. What, inform modders, lol, but anybody can just diff the source from git!

Back in the days before Spring was even released for the first time, the SY went to the length of hard coding hacks for certain mods (SWTA lasers comes to mind). Nowaday, the devs introduce bugs and regressions, then call them "feature" and "for the greater good", and "sure right now it breaks stuff and adds nothing, but on the long term I feel it is more elegant" and "anyway, your mod wasn't doing it the way I say it should be done", and then not bother fix the engine. Why would they, after all if CA can workaround it with a thousand lines of Lua, or if CA is not affected because it doesn't use the feature, then there's no point in fixing the engine.




But, yet, modders can still keep their shit playable, as long as they stay around to fix their mod at every release. Ever played an unmaintened mod from a couple releases ago? Unless it's a simple mash-up of old TA units, you're pretty sure to get flooded by error messages if not plain crash.

With the current model of "release not often", I know that, when a new release comes out, I'll have tons of things to fix asap in mods I care for, but at least, once I'm done fixing them, I can drift away for a couple weeks, confident that the mod will be playable even if I'm not here. I can just check Spring front page from time to time, and as long as new version isn't announced, I know I can safely rest from Spring and turn back to playing other video games, watch TV, party hard, get drunk, skyfuck, go outdoor, or whatever.

With Licho proposal of weekly engine release, my mods would be constantly broken, unless I stayed latched to Spring every single day of the year. Have mercy on the modders! Let them rest in peace between releases!

[Licho]

zwsg and Auswachbar i never suggested to release STABLE every week!! Please read properly.

Just TEST version.

Whole point is to keep 2 versions. Stable can be in packages and installer and official release.

And test version will be auto updated by lobbies on demand.

[lurker]

zwzsg, almost everything on that list is a bug. The entire point of this topic right now is to get people testing for bugs.

[Licho]

Please ffs, just trigger the update now.

Im really sick of telling people with 0.1 how to manually update every game and watch people crash/desync each game.

[Otherside]

if wesnoth does it i dont see why spring cant.

(more people play development version of wesnoth than stable even tho its buggy/crashy)


www.wesnoth.org

[Kloot]

if wesnoth does it

major issues holding [frequent updates] back

* [...] doing Spring as CA or wesnoth is much easier said then done [...] CA and wesnoth don't consist of many independently developed systems that all need to be at the right version to work together

read plz ktxbai

Im really sick of telling people with 0.1 how to manually update every game and watch people crash/desync each game.

Worth pointing out: the only thing triggering this entire discussion for the N-th time is that 0.79.0.2 wasn't released / deployed as 0.79.1.0 (since it contains a bugfix that breaks sync with 0.79.0.1, even though the older engine version most likely just crashes when encountering said bug), and nothing more. That (not following the major.minor.patchset convention introduced for this very reason) is a bad idea no matter how frequent updates are.

[Otherside]

wesnoth uses 2 entirely independent installs. Spring could go this path if devs cant be bothered to make it work under one directory

[Tobi]

It works with separate installs for ages already.

Only config variables can conflict but in particular in the past when rate of development was much lower this never happened in practice.

Spring also already works under a single directory.

[lurker]

.2 breaks sync? I thought .1 had no sync and read an arbitrary location in ram at this bug. Wrong?

[Kloot]

Any .0.1 game where the number of teams was <= the number of ally-teams would sync, actually, although the computations wouldn't make much sense (the bugged code was passing team indices for ally-team ones).