0.4.5 release procedure
0.4.5 release procedure
Ok, guys, time to get serious. The procedure for the 0.4.5 release is going to be the following (unless I'm overruled, that is ):
1.) DONE: Creation of the 0.4.5 release branch
The deadline for the creation of the release branch is Sunday, July 26th, 18:00 UTC. Please commit/merge everything that should go into 0.4.5 until then. All PRs should be reviewed and either accepted and merged or rejected for 0.4.5. After the release branch has been created, only fixes should be made on that branch. That said, of course we can make exceptions and still merge some small additions afterwards, but only if there is a good reason for that, the addition isn't likely to create issues, etc.
If anyone has something he/she wants to get in but won't be able to do so in time, please post a respective request here in this thread, and state how much time you think you'll need. We can then consider if we want to postpone the creation of the release accordingly (ultimately that's Geoffs call).
After the release branch has been created, normal development can resume on master for post release things.
2.) Committing all release specific changes to the release branch and compiling changelog
Once the release branch has been created, there are several release specific things that need to be committed, like commenting out the Super Testers etc. I'll do as much of that as comes to my mind immediately, but as it's more than likely that I forget/overlook something, I'll give you guys some time to get things in I missed or didn't think of.
And, of course, the changelog has to be compiled. No RC1 until that's done, naturally.
3.) Producing test builds and RC builds
It's not very likely that there are already no more known issues when the release branch is created. Also, commtting all the release specific things might take a day or two. And even less likely is that the changelog will have been finished...
So I won't be able to produce RC1 on the following Monday, only "normal" test builds, which however will already be based on the release branch. Once all issues are fixed, the changelog is complete, etc., I can produce RC1. Probably announced by my well known countdown threads. Also, I might not strictly adhere to the Monday schedule for the RC builds (no need to wait several days if everything is ready). We'll see how that plays out.
If issues/bugs turn up, they will be fixed, once all issues are addressed, I'll put out the next RC. Lather, rinse, repeat, until a RC is deemed worthy. If fixing stuff between RC builds takes longer than a week, I might put out normal test builds (that are based on the release branch of course) on Mondays.
4.) Declaring a sufficiently issue-free RC build as the official 0.4.5 release
Once we have a RC build that we deem good enough (that, too, will ultimately be Geoffs call), this build will be declared the official 0.4.5 release. The respective commit will be tagged, announcements posted (forum, wiki main page news, Twitter), everyone is invited to make his/her private celebration party at a location of his/her choice, and then it's back to normal business
Any questions, comments, clarifications? Did I miss something? Otherwise, lets move!
EDIT: Updated status 2015-08-10
1.) DONE: Creation of the 0.4.5 release branch
The deadline for the creation of the release branch is Sunday, July 26th, 18:00 UTC. Please commit/merge everything that should go into 0.4.5 until then. All PRs should be reviewed and either accepted and merged or rejected for 0.4.5. After the release branch has been created, only fixes should be made on that branch. That said, of course we can make exceptions and still merge some small additions afterwards, but only if there is a good reason for that, the addition isn't likely to create issues, etc.
If anyone has something he/she wants to get in but won't be able to do so in time, please post a respective request here in this thread, and state how much time you think you'll need. We can then consider if we want to postpone the creation of the release accordingly (ultimately that's Geoffs call).
After the release branch has been created, normal development can resume on master for post release things.
2.) Committing all release specific changes to the release branch and compiling changelog
Once the release branch has been created, there are several release specific things that need to be committed, like commenting out the Super Testers etc. I'll do as much of that as comes to my mind immediately, but as it's more than likely that I forget/overlook something, I'll give you guys some time to get things in I missed or didn't think of.
And, of course, the changelog has to be compiled. No RC1 until that's done, naturally.
3.) Producing test builds and RC builds
It's not very likely that there are already no more known issues when the release branch is created. Also, commtting all the release specific things might take a day or two. And even less likely is that the changelog will have been finished...
So I won't be able to produce RC1 on the following Monday, only "normal" test builds, which however will already be based on the release branch. Once all issues are fixed, the changelog is complete, etc., I can produce RC1. Probably announced by my well known countdown threads. Also, I might not strictly adhere to the Monday schedule for the RC builds (no need to wait several days if everything is ready). We'll see how that plays out.
If issues/bugs turn up, they will be fixed, once all issues are addressed, I'll put out the next RC. Lather, rinse, repeat, until a RC is deemed worthy. If fixing stuff between RC builds takes longer than a week, I might put out normal test builds (that are based on the release branch of course) on Mondays.
4.) Declaring a sufficiently issue-free RC build as the official 0.4.5 release
Once we have a RC build that we deem good enough (that, too, will ultimately be Geoffs call), this build will be declared the official 0.4.5 release. The respective commit will be tagged, announcements posted (forum, wiki main page news, Twitter), everyone is invited to make his/her private celebration party at a location of his/her choice, and then it's back to normal business
Any questions, comments, clarifications? Did I miss something? Otherwise, lets move!
EDIT: Updated status 2015-08-10
Re: 0.4.5 release procedure
Status as of time of this post: We have one PR pending that has been tagged for inclusion into 0.4.5. This constitutes a request to delay the creation of the release branch until this PR has been addressed (one way or the other).
How shall I proceed?
How shall I proceed?
Re: 0.4.5 release procedure
I think make the build anyway, we can merge in Marcel's work if it's fine but it's using a brand new feature that might be buggy so I'd like to confirm it's fine, which can't now be until tomorrow, if others test the scripts then that'd be good, it *looks* fine but without a test run there's always something with that many changes.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: 0.4.5 release procedure
Status update: PR#249 has been re-tagged for the next release after 0.4.5, so we are (currently) ready to proceed as planned.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: 0.4.5 release procedure
Requests:
Add a new step between 2 and 3:
Commit fixes to master, request cherry pick via issue. Vezzra is then in charge of doing the actual cherry pick (if done right git adds all information to identify the picked commit properly) and compiling further changes to the change log as necessary.
Also please add a string freeze phase for updating translations.
Add a new step between 2 and 3:
Commit fixes to master, request cherry pick via issue. Vezzra is then in charge of doing the actual cherry pick (if done right git adds all information to identify the picked commit properly) and compiling further changes to the change log as necessary.
Also please add a string freeze phase for updating translations.
Last edited by adrian_broher on Sun Jul 26, 2015 6:51 pm, edited 1 time in total.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: 0.4.5 release procedure
0.4.5 release branch has been created. I've changed the version number there and in master accordingly (to "0.4.5" and "0.4.5"). I also commented out the Super Tester buildings already, but no further changes. There have been several suggestions here and here (see also follow-up posts) on what settings should be adjusted for the release. What exactly do you guys want to do now?
Re: 0.4.5 release procedure
For commits that are clearly fixes, and where it's obvious that they have to be merged into the release branch, everyone (well, this of course only means the committers) just go ahead and do the cherry picking yourself. Only if you're not sure if a commit shall go into the release branch put in a request.adrian_broher wrote:Commit fixes to master, request cherry pick via issue.
If a request is approved and the commit can be cherry picked without conflicts, I certainly can take care of that. Probably also simple conflict resolution. However, if a fix turns out to be a bit complicated to cherry pick into the release branch, I will ask the original committer to take care of that. After all, he/she knows the code in question best, and I simply won't be able to deal with all the cherry picking, especially if it turns out like last time for the 0.4.4 release. That has been a bit too much...Vezzra is then in charge of doing the actual cherry pick (if done right git adds all information to identify the picked commit properly) and compiling further changes to the change log as necessary.
As the only translation that is actively maintained currently is the French one by Ouaz, that's up to him. Ouaz, how much time do you think you'll need to bring the French translation up to date if changes have gone in that require an update? So I know how long this string freeze phase has to be...Also please add a string freeze phase for updating translations.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: 0.4.5 release procedure
Vezzra wrote:For commits that are clearly fixes, and where it's obvious that they have to be merged into the release branch, everyone (well, this of course only means the committers) just go ahead and do the cherry picking yourself. Only if you're not sure if a commit shall go into the release branch put in a request.
That's already where the problem starts. Merges to the release branch should not happen at all, even if I assume you just used the wrong term other may not and just happily merge or don't even know how to cherry pick.merged
At least I want to brush up the de translation.Vezzra wrote:As the only translation that is actively maintained currently is the French one by Ouaz, that's up to him. Ouaz, how much time do you think you'll need to bring the French translation up to date if changes have gone in that require an update? So I know how long this string freeze phase has to be...
Cjkjvfnby may want to update the russian one.
I would go for 2 weeks for now to update the german one, but honestly I don't know.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: 0.4.5 release procedure
So basically we spend 2 weeks intensive bughunting in the release branch but don't change anything in the stringtable keys (but I can do updates to en.txt if I find stuff that's unclear or wrong as long as I don't change any keys).adrian_broher wrote: At least I want to brush up the de translation.
Cjkjvfnby may want to update the russian one.
I would go for 2 weeks for now to update the german one, but honestly I don't know.
Then hopefully we've squashed as many bugs as we can find and the translations are up to date. Cool.
Mat Bowles
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: 0.4.5 release procedure
For my part, if a change is made to en.txt in the release-0.4.5 branch, I will update the FR file and create a PR the same day (or the next day at worst): I check the stringtables repo (both master and release) every evening around 16H00 GMT / 17h00 CET / 18h00 CEST.Vezzra wrote:As the only translation that is actively maintained currently is the French one by Ouaz, that's up to him. Ouaz, how much time do you think you'll need to bring the French translation up to date if changes have gone in that require an update? So I know how long this string freeze phase has to be...Also please add a string freeze phase for updating translations.
I release every updated file under the CC-BY-SA 3.0 license.
Re: 0.4.5 release procedure
I just pushed to master an AI colonization planning tweak which, while not really being a bug fix, addresses some AI behavior that players had noticed as being inefficient (being too eager to outpost uninhabitable planets for defensive value if the were in the same system as a colony). https://github.com/freeorion/freeorion/ ... eb7e331a44
I'm inclined to ask to roll it into 0.4.5, or at least felt I should raise it for consideration.
I'm inclined to ask to roll it into 0.4.5, or at least felt I should raise it for consideration.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: 0.4.5 release procedure
Hm, doesn't look too complicated, and if it improves AI behavior, I'd also prefer to include it into 0.4.5. Open an issue with the request like Marcel did, if anyone objects, he can/should do that there.Dilvish wrote:I'm inclined to ask to roll it into 0.4.5, or at least felt I should raise it for consideration.
Re: 0.4.5 release procedure
Testing the 1st pre-release, I noticed that some of my latest translations sounds wrong when read in-game (regarding sitrep dismissals and custom sitreps), as I couldn't check them because there wasn't new test builds with these features implemented, due to the SF crash.
Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
I release every updated file under the CC-BY-SA 3.0 license.
Re: 0.4.5 release procedure
No, not necessary, the relevant commits will be cherry picked into the release branch. However, you should be careful to avoid translations of things that have been introduced/changed in master after the creation of the release branch, that would mess up things.Ouaz wrote:Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
Re: 0.4.5 release procedure
And I am about to change that intro message regarding the custom sitreps. I'll do that today, soon, and will submit a PR on it so we can all get in agreement about the language (at least for English), and you should wait for that PR to have some response before you submit a new translation.Vezzra wrote:No, not necessary, the relevant commits will be cherry picked into the release branch. However, you should be careful to avoid translations of things that have been introduced/changed in master after the creation of the release branch, that would mess up things.Ouaz wrote:Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0