FreeOrion

This means that all items on the list of the OP are done now, I've edited the OP accordingly.

Furthermore, all PRs on github that were tagged with the "next release" milestone have been merged. There are now 6 open PRs, shall any of them be considered for 0.4.5, or are all of them post release patches? Please, "speak up now or forever hold your peace"!

On thing that's left is mel's work on saving windows positions:

mel_o wrote:I have a branch on my github fork with a functional but partially-completed feature of saving window positions to the OptionsDB which I'd really like to get finished before 0.4.5. I'm sure it'll be done in time but I thought I'd give a heads-up since I haven't created a PR for it yet (I was waiting on another PR to be merged, will create one soon).

@Mel, what's your status on this? Can you give us an ETA?

Anything else that should be addressed/considered for 0.4.5? "Speak up now or forever hold your peace"! (Yeah, I know, I use that phrase annoyingly often, but I just LIKE it )

I haven't had the chance to look over Sloth's recent troops patch but the quick scan I saw looks good and I'd like to see it in if it works, it's a good grounding for the splitting up of the traits after release.

Updated the calculation of planetary troops:

Geoff's meter_damage/capacity thing is deliberately for post release, beyond that above my paygrade but I like the look of double clicking planets and the production summary rework if they're ready.

MatGB wrote:I haven't had the chance to look over Sloth's recent troops patch but the quick scan I saw looks good and I'd like to see it in if it works, it's a good grounding for the splitting up of the traits after release.

Dilvish already merged that one, so your wish has been fulfilled

Ok, here is my proposal for an updated procedure: Provided nothing serious comes up (and mel doesn't need more time for his saving window positions thing), I plan to create the 0.4.5 release branch on coming Sunday, late afternoon/evening, I'll make a corresponding "countdown" thread a bit later this week (with an exact deadline). Everything that should go in for 0.4.5 needs to be committed to/merged into master until then. If there is something that should go in, but won't be ready in time for the deadline on Sunday, pls post a request to postpone the deadline accordingly in the countdown thread.

After the release branch has been created, we'll need to commit all the necessary release specific changes (adjusted default settings, disabling Super Testers, finishing the changelog etc.). Once that's finished, I'll go ahead and produce RC1.

Important: changelog!!! This can already be worked on prior to the creation of the release branch, but of course has to be finished before I can make RC1. Geoff, as you've proved to be the one who's most efficient in producing that thing, I guess that task will fall to you, if you're willing to...

wrt disabling super testers, why not have a hidden config option to enable/disable it, just like for the dump context menu from objlistwnd that I proposed ? Fo team can then use persistent_config.xml to re-enable it...

If that's ok, I'll do it.

vincele wrote:wrt disabling super testers, why not have a hidden config option to enable/disable it, just like for the dump context menu from objlistwnd that I proposed ? Fo team can then use persistent_config.xml to re-enable it...
If that's ok, I'll do it.

I think this is too content-specific to be hard-coded into the c++ code, which it would have to be in order to be controlled by the OptionsDB. It's quite easy enough to simply disable them for release; anyone can edit them back in if they want to.

Dilvish wrote:I think this is too content-specific to be hard-coded into the c++ code, which it would have to be in order to be controlled by the OptionsDB. It's quite easy enough to simply disable them for release; anyone can edit them back in if they want to.

Can you explain how I can disable them ?

making the AI even weaker is not a good idea in my opinion, better make spawns/resource distribution over the universe more even

vincele wrote:

Dilvish wrote:I think this is too content-specific to be hard-coded into the c++ code, which it would have to be in order to be controlled by the OptionsDB. It's quite easy enough to simply disable them for release; anyone can edit them back in if they want to.

Can you explain how I can disable them ?

Just edit buildings.txt and remove or comment out the "BLD_SUPER_TEST" entry.

Sloth wrote:Just edit buildings.txt and remove or comment out the "BLD_SUPER_TEST" entry.

Thanks.
Would it be interesting to have a single option for debug which enable/disable all such related things : super testers, dump menu entry, etc...

For the content things, is there a way to add some sort of DEBUG tag to what we would like to hide from users ?

vincele wrote:

Sloth wrote:Just edit buildings.txt and remove or comment out the "BLD_SUPER_TEST" entry.

Thanks.
Would it be interesting to have a single option for debug which enable/disable all such related things : super testers, dump menu entry, etc...
For the content things, is there a way to add some sort of DEBUG tag to what we would like to hide from users ?

I think there hasn't been enough content needing to be disabled for Release for us to bother implementing a special handling for it. I will note, though, that for 0.4.5 we don't only want to comment out the SuperTesters takeover building, we also need to comment them out of species.txt.

Is there anything else besides these two items? (The Dump thing doesn't count since we're not in agreement about hiding it and since it is not content.)

Ok, there are two things I found in my mess of lists, and I don't know if they have been taken care of properly (in both cases pls also note the following posts):

* viewtopic.php?p=77496#p77496

* viewtopic.php?p=77497#p77497

Is there anything that still needs to be done there, or can I remove those items from my lists?

Vezzra wrote:On thing that's left is mel's work on saving windows positions:

mel_o wrote:I have a branch on my github fork with a functional but partially-completed feature of saving window positions to the OptionsDB which I'd really like to get finished before 0.4.5. I'm sure it'll be done in time but I thought I'd give a heads-up since I haven't created a PR for it yet (I was waiting on another PR to be merged, will create one soon).

@Mel, what's your status on this? Can you give us an ETA?

I think I've got the features all complete, currently cleaning up the commits on a new branch and I'll make a PR to the main repo when I'm done with re-testing everything, so... a day from now? Not sure what everyone's timezones are but it'll be up well before Sunday at least, should give people plenty of time to look over the changes. After this, I might be able to get some small fixes or tweaks in other areas done before Sunday but that won't be as important.

Vezzra wrote:Provided nothing serious comes up (and mel doesn't need more time for his saving window positions thing),

("her", fyi )

Vezzra wrote:Provided nothing serious comes up (and mel doesn't need more time for his saving window positions thing), I plan to create the 0.4.5 release branch on coming Sunday, late afternoon/evening, I'll make a corresponding "countdown" thread a bit later this week (with an exact deadline). Everything that should go in for 0.4.5 needs to be committed to/merged into master until then.

Although we've made indeed very good progress on quite a lot of things, I got the impression by following the various discussions and comments here on the forum and on github, that there are still a couple of things people would like to get in for 0.4.5.

Some, like the follow-up PR mel wants to do for her "Remember window positions" PR#214 really should go in if possible, as they address issues.

So I've decided to postpone the creation of the release branch and the subsequent RC builds for another week, and now plan to do that on Sunday, July 26th. This should give everyone time to wrap up/polish/complete things and getting in anything you think really should be in 0.4.5. We're not a commercial project, we don't need to try to meet any deadlines at all costs, and can take our time. There's no point in rushing things, that is, insist on the original deadline and trying to squeeze in as much as possible within the next two days. This is more likely to give us more troubles than enabling us to get the release out sooner.

That said, please also keep in mind that we need to draw the line somewhere, or we'll never get out our next release Which means I do not intend to extend the deadline again, unless there is some really serious issue that absolutely needs to be addressed for 0.4.5. So please everyone, use the extra time wisely and, if you've more stuff you want to get in than you can handle until the deadline, pick the things you think most important and leave the rest for later.

If these proceedings meet general approvement, I'll go ahead as I suggested here (absence of serious objections will be taken as general approvement ).

mel_o wrote:

Vezzra wrote:Provided nothing serious comes up (and mel doesn't need more time for his saving window positions thing),

("her", fyi )

Oh... oops? My sincere apologies Thanks for correcting me

In my defence, those forum nicks really don't convey gender, and I can't address everyone who doesn't reveal his/her real name as "it". That would probably even more rude...

Vezzra wrote:

mel_o wrote:

Vezzra wrote:Provided nothing serious comes up (and mel doesn't need more time for his saving window positions thing),

("her", fyi )

Oh... oops? My sincere apologies Thanks for correcting me

In my defence, those forum nicks really don't convey gender, and I can't address everyone who doesn't reveal his/her real name as "it". That would probably even more rude...

"They" is always safe tho, and people complaining about the singular they being bad English need to go back and read their Shaxper and Chaucer

Anyway, to topic.

Dilvish! If there's going to be a delay, would you, um, object too much, if I introduced a new ship into the Energy line? Because I've been putting off Yandonman's energy frigate but it's SOOO VERY PRETTY. I'm thinking make it roughly on a par with the Robotic Hull and go between Compressed Energy and the two bigger beast on the tech chart.

I won't consider it if the AI team say they can't adjust the tech &c but I really want to play around with it...