make spring 95.0 a not enforced release?

[abma]

most lobbies support multiple versions already, current springlobby development version already does, too.

are there other points were we rely on the version set at the lobby server?

not enforced would really simplify many stuff, also it would allow autohost owners / gamedevs to set the version, also they can decide if its fine for their game or not.

i'm not sure if its problematic to have much more different versions on the lobby server running, currently we have 3: 91.0/94.1/development version. also i don't know if the motivation for gamedevs to fix their games for the current engine is high enough.

[Beherith]

I dont think this is a good idea:
- It can result in frustration in newbies, depending on the implementation details.
- In the long run it results in version fragmentation as versions diverge with mutually exclusive features
- Increased engine developer workload in maintaining and bugfixing versions, especially if game developers wish to cherry-pick commits and branch.

[gajop]

I disagree with behe, I too think it shouldn't be enforced.
It's already not enforced in practice, as abma mentioned.
Let's do some rebuttals :

- It can result in frustration in newbies, depending on the implementation details.

Most things can frustrate newbies, not being able to play ZK from SL is one of those.

- In the long run it results in version fragmentation as versions diverge with mutually exclusive features

The main cause for previous version fragmentation was unusable engine versions for certain games. What are content devs to do if an update causes their project to stop working? They shouldn't have to screw over their entire user base because of it. These things have happened and will happen again regardless of the amount of testing done.

- Increased engine developer workload in maintaining and bugfixing versions, especially if game developers wish to cherry-pick commits and branch.

If they want to do it, its their choice, albeit a poor one with this amount of devs.

There is also at least one more reason why it shouldn't be enforced:
- It will allow for easier dev/custom branch engine testing (as everyone can do it on the main server).


That said, people should try to keep their projects updated to newest stable if they can. Maybe keeping the field "springVersion" on the server isn't bad as it can be used to announce the latest stable version. Just no need to enforce it.

[bibim]

Maybe keeping the field "springVersion" on the server isn't bad as it can be used to announce the latest stable version. Just no need to enforce it.

It's already not enforced, there is nothing at server-side disconnecting you if you don't use default engine version.

Tbh I also don't see the benefit of removing this "latest stable version" announcement on client connection?

[Jools]

By the way, are versions older than 82.0 available somewhere?

[abma]

Tbh I also don't see the benefit of removing this "latest stable version" announcement on client connection?

nobody has to update/take care of it.

[jK]

By the way, are versions older than 82.0 available somewhere?

your q is offtopic but here http://springrts.com/dl/

[bibim]

nobody has to update/take care of it.

Oh you mean it is to simplify uberserver administration, so you don't have to update the broadcasted version each time a new engine version is released?

[abma]

Oh you mean it is to simplify uberserver administration, so you don't have to update the broadcasted version each time a new engine version is released?

yes and no. my question is, would this cause problems i don't know about? not enforcing the version wouldn't require a post like "version will be enforced at...". it would really simplify the release progress.

so very desireable if: lobby can auto-download versions or annoys user if he hasn't the correct version. ideally the users shouldn't have to care about the spring version at all.

[scifi]

I dont think this is a good idea:
- It can result in frustration in newbies, depending on the implementation details.
- In the long run it results in version fragmentation as versions diverge with mutually exclusive features
- Increased engine developer workload in maintaining and bugfixing versions, especially if game developers wish to cherry-pick commits and branch.

+1

not enforced would really simplify many stuff, also it would allow autohost owners / gamedevs to set the version, also they can decide if its fine for their game or not.

I can agree with this.

The better solution would be divide the engine releases into beta/stable, release beta versions that dont require people to upgrade, then release stable versions for example each 3 to 4 months if you want to force an overall change.

if people arent ready for 95.0 sure release it as a beta, and give people time to upgrade and fix their games.

But i mean its your workflow you guys should decide whats best for you.

my 2 cents.(maybe this is probably already done and im day dreaming)

[Silentwings]

Is the current SL dev version able to autodownload and manage multiple engine versions? I know it has support in terms of version check, but without auto-dl it seems mad to me to not enforce the current latest stable engine.

Also, the current SL dev version still has some annoying bugs, without a fully functioning SL I could see forcing a SL upgrade causing problems.

Also what behe said I think could be a problem, or at least would need some discussion (might already have happened, I don't know) amongst the engine devs as to how to cope with:

- In the long run it results in version fragmentation as versions diverge with mutually exclusive features
- Increased engine developer workload in maintaining and bugfixing versions, especially if game developers wish to cherry-pick commits and branch.

Another potential problem maybe: I hate it, you hate it etc etc but if tasclient breaks (even more than already?) (does anyone know if/who mantains it now?! I could find no project page or docu) there might be baw.

Lastly, I agree that, even if its not enforced, keeping an announcement of the latest stable is important.

[abma]

Another potential problem maybe: I hate it, you hate it etc etc but if tasclient breaks (even more than already?) (does anyone even know if/who mantains it now?! I could find no project page or docu) there might be baw.

no, satirik refused to (or just didn't) setup such a page / move to github to make these things clear. that is all i know about it: http://springrts.com/wiki/Lobby_Development#TASClient

[bibim]

yes and no. my question is, would this cause problems i don't know about? not enforcing the version wouldn't require a post like "version will be enforced at...". it would really simplify the release progress.

If you want to stay compatible with clients not supporting multi-engine protocol, of course it will cause problems, because no one will be able to tell which version such a client is hosting...

If you consider these clients will be negligible when Spring 95 is released, then I don't understand why you are still speaking of "enforcement". There is absolutely no enforcement for clients supporting multi-engine protocol, this wouldn't make sense. It's just an announcement for "a default version", "a latest stable version", "a version enforced for legacy clients", whatever you want to call it.

And concerning the "version will be enforced at..." message, I guess the dev team will still write such a post when a new release is out, which should basically have the same content except the "will be enforced at..." will be replaced by "has just been released". Once again I don't see how that would really simplify the release process.

[abma]

And concerning the "version will be enforced at..." message, I guess the dev team will still write such a post when a new release is out, which should basically have the same content except the "will be enforced at..." will be replaced by "has just been released". Once again I don't see how that would really simplify the release process.

a release can be just done, no need for last minute-fixes of games. when "enforcing" all games have to work with the current stable release, without enforcement they can switch over to the current version, when the game is fixed.

yep, the release post/message is a have to, makes no sense without it

i'm aware that all lobby-client / autohosts have to support multi-version when doing this. the lobby server can check the compatibility flag and if not set print a big fat warning.

[smoth]

I THINK the engine should not move away from enforced until we can have each engine version available in the base folder. Right now we cannot do this and springlobby only runs with 1 version at a time.

[zwzsg]

How is a game supposed to declare the version of engine it wants?

[bibim]

a release can be just done, no need for last minute-fixes of games. when "enforcing" all games have to work with the current stable release, without enforcement they can switch over to the current version, when the game is fixed.

Thank you for remembering the benefits of no enforcement (which are the reason why the multi-engine protocol extension has been made), but I'm trying to explain you there is already no enforcement for lobby clients implementing multi-engine...

The "enforcement" isn't related to the server announcing a "latest stable version" or not, it's related to lobby clients implementing multi-engine or not.

You can announce 95.0 in the server right now, my SPADS hosts on engine 94 will still have their battles open and announced as using engine 94, and lobby clients which implement multi-engine will still be able to connect to them and play on them normally. It's the goal of multi-engine, no enforcement, no need to remove the announced default version for that.

i'm aware that all lobby-client / autohosts have to support multi-version when doing this. the lobby server can check the compatibility flag and if not set print a big fat warning.

I though you were concerned about legacy clients that's why I asked, but it seems not so I really don't understand.

[gajop]

How is a game supposed to declare the version of engine it wants?

It's not, autohost should.

[abma]

How is a game supposed to declare the version of engine it wants?

It's not, autohost should.

thats one problem that we will have without "enforced" version. autohosts with the same game will host different engine versions... imo that would be really bad. not sure how to solve this. one game should be hosted with the same engine version, else it will be a hell to maintain for game devs.

maybe games have to ship with the engine version(s) it needs.

[smoth]

If the spring binary, dlls, resources etc were all in a sub dir..

lobby sees game requires different version through some currently non existent magic.

lobby downloads that version into subdirectory..>

???

Profit.

of course it would require storing all the current engine related what's-its in a sub directory of spring. which would mean a major change to spring but hey, if you are going to have multiple versions for all in any sort of user friendly way I would consider this a logical step.