Getting ready for 0.4.4

[Vezzra]

We have started to consider what's left to be done for 0.4.4 here, I think it's time to nail things down

@Geoff: Besides MatGBs patch for the damage control techs, do you want to wait for other things prior to initial RCs? There are some smaller patches floating around (like here, here and here, and maybe some things I missed), anything that should go into 0.4.4?

Otherwise, do I have your ok to go ahead with the RC procedure once MatGB provides his final patches?

@Everyone else: Anything you can think of that needs to be done in preparation for 0.4.4?

The one thing I want to bring up (I know I'm persistent, but this one thing needs to be done, as tedious as it is): changelog! MatGB already has done quite a big job, but the thing needs to be completed, reviewed, probably some amendments, etc.

[Geoff the Medio]

There are some smaller patches floating around (like here, here and here

The first can be committed if it works for you and gets all the discussed pedia X's (and I'll probably do so when I get a chance later, but can't immediatley). The second has no patch posted. I don't think the 3rd is needed, so unless there's several people demanding it's addition, I wouldn't bother.

The other issue that comes to mind is inconsistencies with visibility of objects after battles. I probably won't have time to dig into it in the next day or so...

[adrian_broher]

@Everyone else: Anything you can think of that needs to be done in preparation for 0.4.4?

Fix the Windows SDK so we can point at when releasing 4.4. I want to continue with my pure cmake SDK-less setup on all platforms but this change is a blocker for month now.

The one thing I want to bring up (I know I'm persistent, but this one thing needs to be done, as tedious as it is): changelog! MatGB already has done quite a big job, but the thing needs to be completed, reviewed, probably some amendments, etc.

We should change the changelog maintaince for the next cycle: Instead of scrapping informations of of the commit log at the end of development cycle add user relevant changes when commiting to the repository. It's easier to delete irrelevant/outdated informations at the end or during the development instead of searching and missing them.

Also please fork the release so I can continue on trunk.

[Geoff the Medio]

Fix the Windows SDK...

Changing the SDK is something I would wait until after a release to start doing. Aside from any other reasons, it's likely to be disruptive and cause short-term build problems, whereas the existing SDK(s) are stable and useful to build v0.4.4.

We should change the changelog maintaince for the next cycle:

It's been discussed elsewhere, and even if it were to happen, it's not something we'd do before v0.4.4, which is the point of the thread...

Also please fork the release so I can continue on trunk.

Could you elaborate / rephrase this request so it's clear what you're asking?

[adrian_broher]

Could you elaborate / rephrase this request so it's clear what you're asking?

I would like to continue developing on trunk without distrupting the release process so I ask you to create a branch for the release candidate where fixes can be applied.

[Vezzra]

The first can be committed if it works for you and gets all the discussed pedia X's

Well, it looks like it's still WIP, and I usually wait until you approve a patch and request test on other platforms before I run tests on OSX. It doesn't look like it's going to cause trouble on OSX, but if you want me to test this one before you commit it, just leave me a note

(and I'll probably do so when I get a chance later, but can't immediatley).

We're in no hurry. Take your time

The other issue that comes to mind is inconsistencies with visibility of objects after battles.

Of course, you're right, I completely forgot that one (sorry Dilvish). Unfortunately, I can't help you guys with that one, I haven't encountered it in my own test games, and I've never dug into the respective code parts.

I probably won't have time to dig into it in the next day or so...

Well, as I already said: No hurry. The purpose of the thread wasn't a try to hurry things up, just to focus our folks on fixing stuff and finalizing their various projects, and to refrain from starting new things, or we'll never get this release out

[Geoff the Medio]

...I usually wait until you approve a patch and request test on other platforms before I run tests on OSX.

This doesn't appear to need any OS-specific testing. If it works fine for you, it can be committed.

[vincele]

Hello, the EncyclopediaDetailPanel X button patch should (hopefully) be in its final iteration so testing is welcome.

And I'll second the idea of branching (if it's not too much additional work) to let the release stabilization process not block trunk

[Vezzra]

This doesn't appear to need any OS-specific testing. If it works fine for you, it can be committed.

Looks like you've already done this, so one thing less on our list

Ok, let's see what's left to be done:

• MatGBs Damage Control patch
• Visibility of objects after battles issue

These two need to go in / get resolved prior to initial release candidates. Then there is another issue and another patch suggested:

• Server crashes in moderator mode issue
• Word wraps in sitreps patch

Do you want to consider any of them for 0.4.4?

[Geoff the Medio]

Word wraps should probably be after as it's likely to be glitchy in not immediately obvious ways.

Intermittent crashes are always happening... If this one can be isolated and fixed, fine, but I don't think it's worth waiting weeks for...

[Vezzra]

Word wraps should probably be after as it's likely to be glitchy in not immediately obvious ways.

Intermittent crashes are always happening... If this one can be isolated and fixed, fine, but I don't think it's worth waiting weeks for...

Ok, then I propose doing the following:

• Postponing the word wrap patch post 0.4.4
• As the visibility issue has to be resolved anyway, if the server crash in moderator games issue can be fixed in the meantime too, fine, if not, don't hold up 0.4.4 because of it

I'm going to put up the usual weekly test builds today. Next Monday I'd already want to put up RC1, assuming that one week will be sufficient to solve the visibility issue and give MatGB's Damage Control patch enough initial testing (which is why I'd like the latter committed before I make today's test builds).

Besides that: What do you think of the idea of making a branch for the 0.4.4 release? I know you haven't been particularly fond of that idea in the past, but it's not an uncommon practice and would allow people to resume working on trunk, so maybe we can try it this time...?

[Geoff the Medio]

What do you think of the idea of making a branch for the 0.4.4 release?

If adrian_broher thinks it's necessary, fine...

[MatGB]

Things I want done entirely in the stringtable that don't affect gameplay or code:

1) Rewrite all the Stealth tech descriptions to show they add specials to all controlled planets, and rewrite the specials to indicate they might be granted by higher end techs.

2) Go over and complete the update to the Hull descriptions to standardise them in the way I started with the Organic line

3) Checkover the rest of the stringtable for egregious errors or outdated text. eg Scattered Asteroid Hull references a different hull that doesn't exist in its description, noticed this yesterday

There sill undoubtedly be other minor cleanups needed to en.txt—and anyone that doesn't feel up to coding but spots errors, etc that reads this should feel free to comment to the thread about en.txt in the translations area and I can combine and patch stuff, even if you just spot an error.

Something I'd like to try to do that isn't necessary but would be cool: a Victory sitrep for a conquest victory, triggered, probably, by the player controlling all inhabited worlds, I tried doing this once before when doing the Experimentor one but I've learnt a lot since then. If that can't be done, so be it, it shouldn't hold things up, butif it can be it would be nice to get all three potential victories telling the player that they're completed (of course, there's nothing telling other players they've lost, yet which would be an issue in multiplayer).

[Dilvish]

As the visibility issue has to be resolved anyway

I don't think this should hold up 0.4.4. -- I've gotten convinced that the planned combat visibility handling I had thought was previously in place for a while, really wasn't, it simply hadn't come up so clearly. The recent change was simply that stealthed Organic Hulls brought the issue up more much more often, not that the recent CombatSystem changes affected visibility. I am hoping Mitten might still take on the task of enabling combat-triggered visibility, which would be wonderful to get into 0.4.4, but I don't think we should count on it. Plus per the discussion in the hull balance thread I just put the Organic Hull stealth back to 5, which removes some of the heat regarding this issue.

if the server crash in moderator games issue can be fixed in the meantime too, fine, if not, don't hold up 0.4.4 because of it

I can no longer replicate the problem and Geoff can't either. Even if the issue is still lurking, I agree that a moderator mode crash isn't something I think we need to hold up 0.4.4 for.

I don't think I personally have any more tasks that should be gates for 0.4.4. If anyone else thinks there is some such task I have taken responsibility for, please speak now or forever hold your peace.

[Vezzra]

What do you think of the idea of making a branch for the 0.4.4 release?

If adrian_broher thinks it's necessary, fine...

Well, he specifically requested making a release branch (so apparently he thinks it's necessary). A release branch also would have the benefit that in case some major bug turns up after the release, we could issue a bugfix release. So, if that's ok with you, I'd like to try it out for this release.

However @adrian_broher: I'm an absolute newbie when it comes to branching and merging. I have read up a bit on the topic though, and if I understand correctly, the whole process works as follows: Creating a branch by copying trunk to e.g. branches/rel-0.4.4 (done with svn copy), then continue committing further development work and fixes to trunk. Those fixes that should get into the release are merged into the release branch by the "cherry-picking" method (done with svn merge). Produce our release candidate builds based on the release branch. Once we decide that a release candidate proved to be sufficiently stable, declare the build as the official release (as we've already been doing before). Optionally tag the release branch by svn copy e.g. to tags/rel-0.4.4. If we want to go overboard, we can tag every RC build ("rel-0.4.4.rcX") and rename the final one ("rel-0.4.4").

Did I get that right, or did I miss something important / completely misunderstood how that works at all?