Plans to make a New Release? - Minor version to 4.4.3 with all latest committed changes / patches.

[Chewbakka-Wakka]

I see 4.4.2 was out in Nov.

Since then quite a number of patches / commits have been made.

Is it time for 4.4.3?

[vaut]

https://github.com/Warzone2100/warzone2100/milestone/36

[Monsterovich]

Would love to see this and maybe this in the next issue.

[Chewbakka-Wakka]

I do wonder how it is the milestones are chosen for a given release, as I had a couple ideas to share that I defo think would be things people want to see.

[Chewbakka-Wakka]

Since 4.4.2 - I have now seen about 332 patches go out... May I ask therefore for a minor release to be made in the interim until such time when the milestones are reached for the Major one?

4.4.3 - Minor 4.5.0 - Major

[kloczek]

Looking on https://github.com/Warzone2100/warzone2100/compare/4.4.2...master it would be really good to make new (minor?) release 🤔

WZ has really high rate of commits to IMO it would be really good to have minor release every 100-150 commits. Is it doable to have such releases in the future? 🤔

PS. Generally more frequent releases than better because it is easier to encircle possible causes of some issues between releases.

[past-due]

Our release cadence is currently:

1. “Major” release with larger changes that require more testing (this usually has at least one beta / pre-release before it becomes stable)
2. Followed by (potentially) one or more bug-fix / “point” releases to address critical issues discovered in that new major release to get it to a comfortable point of stability (and compatibility)
3. Followed by a period of development and merging of larger changes again, leading up to the next “major” release

We are currently in phase 3 of this. And usually in this stage there’s a lot of testing and tweaking that happens before the master branch is again ready to proceed to even the pre-release of a new “major” release.

You are, of course, welcome to test development builds of the master branch if you like, but as you may also notice we’ve been busy fixing issues so its stability is expected to vary.

[kloczek]

We are currently in phase 3 of this. And usually in this stage there’s a lot of testing and tweaking that happens before the master branch is again ready to proceed to even the pre-release of a new “major” release.

OK good to know 😄 👍

You are, of course, welcome to test development builds of the master branch if you like, but as you may also notice we’ve been busy fixing issues so its stability is expected to vary.

Issue is that incorporating list of patches in builds procedures taken from commits beyond some number of such patches usually if commits non-sequential creates some rejections 😞 (all because it is harder to figure out which one patches should be reordered).

[past-due]

Issue is that incorporating list of patches in builds procedures taken from commits beyond some number of such patches usually if commits non-sequential creates some rejections 😞 (all because it is harder to figure out which one patches should be reordered).

Other than compilation fixes (and please let me know if any are needed so we can upstream them for the next release), I wouldn’t recommend incorporating any other patches. Many core changes (the sorts of things that go into a new “major” release) run the risk of changing the deterministic simulation, and thus breaking multiplayer compatibility.

[Chewbakka-Wakka]

"run the risk of changing the deterministic simulation, and thus breaking multiplayer compatibility." - Yes this something I was aware of but forgot to mention initially...

Perhaps we/I (on my side) can filter on only including patches that are "compilation fixes" This would require a common lets paraphrase as "naming convention" for all such patch commits made. We just need to know what to look for.