make spring 95.0 a not enforced release?
Moderator: Moderators
make spring 95.0 a not enforced release?
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.
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.
Re: make spring 95.0 a not enforced release?
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.
- 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.
Re: make spring 95.0 a not enforced release?
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 :
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.
It's already not enforced in practice, as abma mentioned.
Let's do some rebuttals :
Most things can frustrate newbies, not being able to play ZK from SL is one of those.- It can result in frustration in newbies, depending on the implementation details.
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.- In the long run it results in version fragmentation as versions diverge with mutually exclusive features
If they want to do it, its their choice, albeit a poor one with this amount of devs.- Increased engine developer workload in maintaining and bugfixing versions, especially if game developers wish to cherry-pick commits and branch.
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.
Re: make spring 95.0 a not enforced release?
It's already not enforced, there is nothing at server-side disconnecting you if you don't use default engine version.gajop wrote: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.
Tbh I also don't see the benefit of removing this "latest stable version" announcement on client connection?
Re: make spring 95.0 a not enforced release?
By the way, are versions older than 82.0 available somewhere?
Re: make spring 95.0 a not enforced release?
nobody has to update/take care of it.gajop wrote:Tbh I also don't see the benefit of removing this "latest stable version" announcement on client connection?
Re: make spring 95.0 a not enforced release?
your q is offtopic but here http://springrts.com/dl/Jools wrote:By the way, are versions older than 82.0 available somewhere?
Re: make spring 95.0 a not enforced release?
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 wrote:nobody has to update/take care of it.
Re: make spring 95.0 a not enforced release?
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.bibim wrote: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?
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.
Last edited by abma on 07 Oct 2013, 19:28, edited 1 time in total.
Re: make spring 95.0 a not enforced release?
+1I 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.
I can agree with this.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.
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
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: make spring 95.0 a not enforced release?
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:
Lastly, I agree that, even if its not enforced, keeping an announcement of the latest stable is important.
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:
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.beherith wrote: - 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.
Lastly, I agree that, even if its not enforced, keeping an announcement of the latest stable is important.
Last edited by Silentwings on 07 Oct 2013, 20:07, edited 1 time in total.
Re: make spring 95.0 a not enforced release?
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#TASClientSilentwings wrote: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.
Re: make spring 95.0 a not enforced release?
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...abma wrote: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 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.
Re: make spring 95.0 a not enforced release?
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.bibim wrote: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.
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.
Re: make spring 95.0 a not enforced release?
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.
Re: make spring 95.0 a not enforced release?
How is a game supposed to declare the version of engine it wants?
Re: make spring 95.0 a not enforced release?
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...abma wrote: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.
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 though you were concerned about legacy clients that's why I asked, but it seems not so I really don't understand.abma wrote: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.
Re: make spring 95.0 a not enforced release?
It's not, autohost should.zwzsg wrote:How is a game supposed to declare the version of engine it wants?
Re: make spring 95.0 a not enforced release?
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.gajop wrote:It's not, autohost should.zwzsg wrote:How is a game supposed to declare the version of engine it wants?
maybe games have to ship with the engine version(s) it needs.
Re: make spring 95.0 a not enforced release?
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.
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.