0.4.5 release procedure

Discussion about the project in general, organization, website, or any other details that aren't directly about the game.
Message
Author
User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

0.4.5 release procedure

#1 Post by Vezzra »

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. :mrgreen:

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! :D

EDIT: Updated status 2015-08-10

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#2 Post by Vezzra »

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?

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: 0.4.5 release procedure

#3 Post by MatGB »

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.

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#4 Post by Vezzra »

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.

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: 0.4.5 release procedure

#5 Post by adrian_broher »

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

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#6 Post by Vezzra »

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?

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#7 Post by Vezzra »

adrian_broher wrote:Commit fixes to master, request cherry pick via issue.
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.
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.
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... ;)
Also please add a string freeze phase for updating translations.
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...

User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: 0.4.5 release procedure

#8 Post by adrian_broher »

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.
merged
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.
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...
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.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
MatGB
Creative Contributor
Posts: 3310
Joined: Fri Jun 28, 2013 11:45 pm

Re: 0.4.5 release procedure

#9 Post by MatGB »

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

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.

User avatar
Ouaz
Dyson Forest
Posts: 232
Joined: Wed Aug 13, 2014 7:21 pm
Location: France

Re: 0.4.5 release procedure

#10 Post by Ouaz »

Vezzra wrote:
Also please add a string freeze phase for updating translations.
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...
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.
I release every updated file under the CC-BY-SA 3.0 license.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: 0.4.5 release procedure

#11 Post by Dilvish »

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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#12 Post by Vezzra »

Dilvish wrote:I'm inclined to ask to roll it into 0.4.5, or at least felt I should raise it for consideration.
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.

User avatar
Ouaz
Dyson Forest
Posts: 232
Joined: Wed Aug 13, 2014 7:21 pm
Location: France

Re: 0.4.5 release procedure

#13 Post by Ouaz »

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?
I release every updated file under the CC-BY-SA 3.0 license.

User avatar
Vezzra
Release Manager, Design
Posts: 6090
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: 0.4.5 release procedure

#14 Post by Vezzra »

Ouaz wrote:Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
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.

User avatar
Dilvish
AI Lead and Programmer Emeritus
Posts: 4768
Joined: Sat Sep 22, 2012 6:25 pm

Re: 0.4.5 release procedure

#15 Post by Dilvish »

Vezzra wrote:
Ouaz wrote:Whatever, I can create a PR for the master branch, but should I create a PR for the release branch too?
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.
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.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Post Reply