Maintenance branch

[hokomoko]

I've added a maintenance branch of spring that contains most non-opengl changes since 104.0.
This is done as a temporary measure to keep new engine changes tested so bugs don't get the opportunity to ferment.

A few guidelines:

1) No commits or pull requests will be made directly to this branch, only cherry-picks from develop
2) Bug reports on this branch will only be investigated (by me) if the reporter clearly states whether it can be reproduced on the develop branch or not (unless impossible, e.g., desyncs).
3) If there's a non-opengl change that I haven't ported to the branch even though I should have, contact me through PM or through #sy

[Kloot]

.

[raaar]

Why does this require a new branch?

why is kloot writing "." ?

[hokomoko]

Why does this require a new branch?

That way it allows breaking and WIP openGL changes to continue unhindered in develop.

[abma]

https://springrts.com/mantis/view.php?id=5812
https://springrts.com/mantis/view.php?id=5811

(it doubles the work for testers / the diff from develop to the maintainance is huge. possible bugs are found in maintainance which aren't in develop and vice versa)

i don't see this plan going to work both reports ignored rule 2. it seems.

imo its more effective to test current develop and report bugs as usual. if we have to many breaking stuff, the breaking changes should be made on a branch.

[Silentwings]

I guess the intention is that all play-testers should use the maintenance branch until, at some point in future, the develop branch is announced as "finished the GL upgrade", at which point we'll go back to testing develop?

[hokomoko]

I guess the intention is that all play-testers should use the maintenance branch until, at some point in future, the develop branch is announced as "finished the GL upgrade", at which point we'll go back to testing develop?

Not quite "finished", but when stability returns to be a higher priority in develop, or when

i don't see this plan going to work both reports ignored rule 2. it seems.

Actually in both cases reproducing wasn't applicable, so reports were ok.
The point is that this plan was my idea of what I can do personally to keep the engine tested as much as possible, while allowing games to have a playable version with fixes for bugs present in 104.0.
I'm not surprised that some think it's an incorrect approach, this way of work was chosen partially because I can implement it by myself.

[abma]

Actually in both cases reproducing wasn't applicable, so reports were ok.
The point is that this plan was my idea of what I can do personally to keep the engine tested as much as possible, while allowing games to have a playable version with fixes for bugs present in 104.0.
I'm not surprised that some think it's an incorrect approach, this way of work was chosen partially because I can implement it by myself.

i guess kloot has to say if the maintainance branch helps him or not... lets see. there is no clear right or wrong here.

[raaar]

Having engine devs using the same branch makes it more likely that they'll stumble upon each other's bugs before they hit the rest of the community.

[cleanrock]

I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested and you do not have to worry about commits with both GL and other changes.

[sprunk]

I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested

If you let ZK handle it then ZK just stays at 104.0 for a while and the GL changes will not be tested. Note that with maintenance branch they do not get tested either but at least the non-GL ones do.

[cleanrock]

sprunk, that is only if game(zk) devs do not have the time or will to test develop.
I suspect hokomoko and perhaps even kloot are willing to contribute to that zk branch if zk devs do not have time/will for it.
Imo, it is clear all develop changes should be tested by game devs and testers like me since develop changes are not thoroughly tested by "upstream".
I think it will be difficult to only get the non-GL changes from develop to the maintenance branch, e.g. I bet kloot is not keen on separating commits for that.

[Forboding Angel]

But what about the rest of us? Do we get special engine Dev help as well? ZK already has an army of devs compared to the rest of us. After all of that, If zk needs help from engine devs, then the rest of us are probably screwed.

[PicassoCT]

So if you ever had beef with kloot- wait some time, fork this branch and implement some graphics heavy feature for spring. Got it !

[gajop]

@forb I think the intention is that all devs can rely on it, so you too should talk to hokomoko

My main worry with this approach is that it has a chance of leading to a gl3/4 engine fork if content devs decide not to use gl4. I see little guarantee or exact schedule for this things temporariness.

[Google_Frog]

Here are my thoughts on the branch: https://github.com/ZeroK-RTS/Zero-K/issues/2547.

On testing - I think testing carried out by a small pool of testers is ineffective. This reflects well on the stability of the engine. In the months leading up to 104.0 almost all the bugs were either rare or hardware specific. The former type requires many players playing many games to find and the latter type are mostly impossible to find with my hardware. We've only found these bugs by tracking the dev engine as the live engine on the server. My testing prior to making an engine live amounts to running an AI game (to check for obvious synced bugs) and testing bugfixes.

But what about the rest of us? Do we get special engine Dev help as well? ZK already has an army of devs compared to the rest of us. After all of that, If zk needs help from engine devs, then the rest of us are probably screwed.

I don't understand this viewpoint. What is being done with the engine which you are unable to take advantage of? You can use the maintenance branch and you could have been tracking develop earlier to get all the latest fixes. Why aren't you just glad that someone was testing develop on players?

I suggested to let games(zk) handle this: https://github.com/ZeroK-RTS/Zero-K/issues/2535
I think this is better since the GL changes will be tested and you do not have to worry about commits with both GL and other changes.

I don't see hpw that ticket is relevant or what needs handling there which is related to engines.

[cleanrock]

I don't see how that ticket is relevant or what needs handling there which is related to engines.

I guess you only want to use non-breaking changes because the zk selected 104 was bad in some way, i say this because https://github.com/spring/spring/commit/6971132e was excluded from maintenance.
Perhaps this is a good idea but at some point all changes need to be tested to move forward with your model (must be tested in public games and revert engine if fail).
I think zk should have test hosts running a zk-test version/branch using a selected spring/develop but perhaps the current low player base do not make this a realistic option if many big public games are required.
It all looks a bit messy to me but perhaps you guys have a good plan.

[hokomoko]

I guess you only want to use non-breaking changes because the zk selected 104 was bad in some way, i say this because https://github.com/spring/spring/commit/6971132e was excluded from maintenance.

This commit was excluded due to my error, it was actually in the list of things ZK wanted to port.

In general - breaking changes are planned to be included in the maintenance branch. If there are more commits that I've missed please point them to me.

[abma]

In general - breaking changes are planned to be included in the maintenance branch. If there are more commits that I've missed please point them to me.

seems the branch wasn't updated since 13. Nov. i.e. https://github.com/spring/spring/commit ... 8a3c2e6618 :)

[hokomoko]

I've updated maintenance branch, builds should be up somewhen. Breakages are quite possible.