Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Chewbakka-Wakka opened this issue Mar 17, 2024 · 9 comments
Labels

Comments

@Chewbakka-Wakka
Copy link

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
Copy link
Contributor

vaut commented Mar 17, 2024

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

@Monsterovich
Copy link
Contributor

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

@Chewbakka-Wakka
Copy link
Author

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
Copy link
Author

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

@Chewbakka-Wakka Chewbakka-Wakka changed the title Plans to make a New Release? Plans to make a New Release? - Minor version to 4.4.3 with all latest committed changes / patches. Mar 29, 2024
@kloczek
Copy link

kloczek commented Mar 29, 2024

Looking on 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
Copy link
Member

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
Copy link

kloczek commented Mar 29, 2024

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
Copy link
Member

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
Copy link
Author

"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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants