FreeOrion

I think it's time to start planning for the 0.4.8 release. Which means we should start to determine what needs to go into/is mandatory for that release, and what can wait for later. The original intention has been to get 0.4.8 done by the end of the year, to (probably) no one's surprise it will take us a bit longer (most likely).

So I've split up the "v0.4.8" milestone into three:

• "v0.4.8 (mandatory)": for issues/PRs that absolutely need to be fixed/finalized, and are therefore release-blocking.
• "v0.4.8 (optional)": for issues/PRs that can or mayby should go in, but are not absolutely needed, and therefore do not block the release.
• "post v0.4.8": for issues/PRs that should be postponed until after the release, these are issues/PRs that would take too much time and effort and would delay the release too much.

I've done a first pass and went over all the open issues and PRs, and and tried to assign them to one of these milestones as best as I could. As your assessment might be different, please, everyone, take a look at these milestones and the issues/PRs assigned to them and post your feedback here. If you think an issue/PR should be reassigned, make a proposal and state your reasons, so we can discuss it.

As you can see, I've considered only a few issues/PRs as mandatory, consequently it looks like 0.4.8 is almost done (97%). This of course is misleading, because there are actually two major items which will take quite some time and effort to fix/complete: the major feature of this release, the Imperial Stockpile, and the logging issues on OSX (the latter being a big headache IMO).

The implementation of the Imperial Stockpile feature itself seems close to completion (thanks to Geoff picking it up after there hasn't been any progress for a while now). However, the new feature needs some serious playtesting and refinement before it can be considered ready for release. I suspect the intial content in particular will probably need some serious adjustments. Furthermore, the AI needs to be able to have at least basic capability to handle the new feature. @AI team, any idea/estimations how much work this is going to be?

The issues with the broken logging on OSX is a major problem: Apparently the solution to that requires changes to the build setup (the boost libraries need to be shared instead of static libraries), which require changes to the OSX SDK that are blocked by an issue we haven't been able to resolve so far. Although a solution has been proposed, apparently it's not a very good one (a temporary hack at best), and adrian_broher raised serious objections. However, the logging issues on OSX need to be fixed for the release, so we need to reach an agreement there, I think this might become the major holdup for 0.4.8. If anyone has an idea how to solve that mess, that would be appreciated very much...

Comments, opinions, suggestions, etc.?

Very basic handling of the feature should be pretty easy/quick to implement-- the AI could simply always enable the first item in its queue to draw from the stockpile. As far as something more advanced goes, I haven't looked at the stockpile in a while, but the expectation was that there would be some techs for expanding the stockpile size and efficiency, we should probably be able get them worked into the AI research planning someplace at least, even if it might be at a lower priority than a human player would use for them. The best use from my recollection of stockpile planning would be for the AI to consider any resource groups it has that are separated from its main resource group, and figure out if any items in those are critical enough that they should be given stockpile privilege. Doing that really well might be quite tricky, but it could be that figuring out some sort of reasonable-and-better-then-nothing rule might not be too bad. I am likely still pretty swamped for most of November, but will try to squeeze in some stockpile review.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

As there hasn't been much feedback, I assume you guys more or less agree with what I've considered mandatory for the release and what not. The broken logging on OSX has been resolved, and the major feature of this release (Imperial Stockpile) has been merged, which means we should be able to wrap things up in the foreseeable future.

What remains to be done:

First of all, it would be good if as many of you as possible would playtest the new mechanic in particular now, and give your feedback. I consider what went in as still very rough around the edges and in need of polishing before we can deem this ready for release. In particular the content provided needs a major overhaul, IMO. What we have is perfectly fine for playtesting, as it gives you easy access to the new feature in test games. But the Imperial Stockpile techs/tech tree and the fluff explanations can certainly be improved, and being able to use the stockpile definitely shouldn't be something available right from game start.

Second, there are the issues and PRs mandatory for 0.4.8. I urge all our (active) devs to give those priority now, so we can clear that list. We can't proceed with the release until every item on that list has been finished.

It would be great if we could get 0.4.8 out by the end of January. If that's not possible, then by the end of February at the latest. Hopefully.

There is a lot that I'd still like to do, not all really bugfixes, but won't have much time for until the end of this month, so end of January seems a bit a bit tight on time-- I'd like to be able to introduce some non-bugfix code at least up through the middle of January.

I've followed up in Oberlus' feedback thread...

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

I have two questions: Is hostless an essential feature for v0.4.8?

If it is not, then bugs Heap-buffer-overflow in creating universe in the second game session. and Segfault on second session in hostless mode should not be on the mandatory list.

If hostless is an essential feature for v0.4.8, then I think that there are more unfound bugs because it changes a key assumption in the original design of the server, that it would be shutdown between games.


Could we change the names of the "v0.4.8(optional)" and "post 0.4.8" to something generic? When we release v0.4.8 all the timestamps on those issues will be reset when the issues are moved to the next version number. It is easier to track what issues are hot/current and what issues are not when sorting by timestamp is meaningful.

Well, if you have some stuff you want to get into 0.4.8 for which you need more time, we can certainly consider that (after all, one of the main purposes of this thread is to make such requests ). What are those things you want to get in?

Are the others ok with delaying 0.4.8? Guesstimating by what Dilvish said and past experiences (it always takes longer than you think), I'd expect a delay until March at the least. Geoff? Mat?

That said, a bit more time might be good anyway. Based on my own playtesting and the feedback that has been provided so far it seems the Imperial Stockpile feature needs some tweaking and balancing before it can be deemed release-ready, which I expect to take some time.

Well, originally 0.4.8 has been intended as a smaller release squeezed in before 0.5 (for which the plan is to introduce Influence, which is going to be a big, major thing) for the introduction of the Imperial Stockpile feature, so no, not really. However, as it has already been merged, it should be at least basically functional and not totally broken, so we can introduce it as an experimental feature.
I'd say, it depends on how badly these bugs break hostless mode. Multiplayer and all related stuff is something I just don't have the time to look at/experiment with, so I can't make any judgement on that.
If it's really so bad that we can't get hostless mode to work at least sufficiently well to pass as experimental feature, then yes, everything related to that feature should be considered optional, not mandatory for the release.

Looks like you (and Geoff) are probably the ones who can judge that best, so I defer this decision to the both of you. Geoff?
While I understand and agree that's an issue, how is renaming those milestones to something more generic supposed to solve anything? Once the release is out, I intend to rename "0.4.8 (optional)" instead of making a new milestone and moving all the assigned issues and PRs anyway, so unless the timestamp of issues/PRs are reset when the assigned milestone is just renamed, there shouldn't be a problem with those. And the issues/PRs assigned to "post 0.4.8" will have to be reassigned to the renamed "0.4.8 (optional)", so their timestamp is going to change regardless how "post 0.4.8" has been named...?

Vezzra, mass changing of milestones causing spurious timestamping is more irksome than a full blown issue.
This might work, but most other re-labelings, reset the timestamp. We will see.
Milestone names could be choosen that do not require immediately moving many/any issues upon releasing a new version.

The current milestones are "v0.4.8 (manadatory)", "v0.4.8 (optional)" and "post 0.4.8".

One way of interpreting their intent is immediate, near future and far future requirements. Releasing v0.4.8 will not immediately make all of "v0.4.8 (optional)" mandatory for the next version. The version numbers could be stripped from the second two milestones. It would improve their utility.

Looked at another way the current milestones correspond loosely to blockers, non-blockers and feature requests.

And in another way, required, desirable, and wished for.

We need a milestone for blocking issues and required features of the next release version. We could name it "vX.Y.Z".

We need a milestone for non-blocking issues, implemented but non-required features and upcoming requested features. We could name it "optional"

We need a milestone for long term works in progress (WIP) and wished for feature requests. We could name it "wishlist.

If we used milestone names like "vX.Y.Z", "optional" and "wishlist, then after release a new milestone named "vX.Y+1.Z" would be created to which a single feature request is moved from "optional. Otherwise nothing would change.

What do you mean by "most other re-labelings"? There are two ways in which milestones of issues/PRs are going to be changed after a release: renaming of a milestone (which should not change the timestamps) and reassigning issues/PRs to another milestone (which of course will change their timestamp). Is there anything else?
Erm, not quite. I guess this could be one reason for our misunderstanding: the "mandatory" and "optional" milestones are exactly that (not correspond loosly to ), release blocking issues/PRs and those that do not block the release. The purpose of the "post" milestone is to mark issues/PRs which shouldn't be worked upon until after the release. Either because they require too much effort and are not important for the release (so would distract too much dev manpower), or would open a can of worms that would delay the release too much.

Or, to phrase it a bit more to the point: "mandatory" = must go in, "optional" = can go in, "post" = should not go in.

Which means the the "post" milestone only makes sense when we're trying to wrap up a release, which in turn means that after a release all the issues/PRs assigned to the "post" milestone have to be reassigned. Unless I'm missing something obvious here, having more generic names for the "optional" and "post" milestone isn't going to help with that...
Right, which is why I intend to rename the "0.4.8 (optional)" milestone to "0.5 (optional)" (or "next release (optional)" if we haven't decided on the version number of the next release). All the "mandatory" issues/PRs have been closed/merged anyway, which only leaves the issues/PRs assigned to the "post" milestone. These are actually the only ones of concern when it comes to the timestamp problem.

The only advantage generic names for the "optional" and "post" milestones would be that renaming them isn't necessary anymore. Given how rarely that happens, I consider that a non-issue. I'd rather have the (IMO) more descriptive names which include the version number, but that's of course more of a cosmetic issue and a matter of personal preference.

The only way to avoid the reassigning of issues/PRs after a release I see would be to give up the "post" milestone.
I'm a bit confused... except the last step, all this is practically the same as the current scheme, just different names for the milestones.

And I don't get that last step: what single feature request are you referring to here? Issues/PRs assigned to "optional" need to be reassigned to "vX.Y.Z" if we decide to promote something from being optional to being required for the next release, which is certainly not restricted to one item, and does not only happen right after a release. Also, this does not cover that items need to be moved from the "wishlist"/"post" milestone to "optional"...?

Sorry, it's not that I'm not open to revising my workflow here, you just need to have a bit more patience with me until I get what you mean.

I meant that changing an issue's label changes its timestamp.
I expect that renaming the milestone will change the timestamp. If renaming the milestone does not change the timestamp, then all of this discussion is moot.
This I misunderstood. I assumed that if new contributor showed up with a fully functional Battle Simulator, before we started test a release candidate, we would help them merge it rather than saying, "Please wait a month or two". That is why I called it the third milestone wishlist.
It is because it is rare that it is an issue. As time progresses we will accumulate issues. In a year we might have 1000+ unresolved minor issues/feature requests. With the current system, after a release renaming the optional Vx.y.z milestone will timestamp all of the issues. An issue that has had no other activity in two years and the latest feature request both look the same. If a new dev is looking for something to implement/fix, it would be better if they selected from a newer issue without trolling through any cruft. With the suggested system, a future maintainer can cull old issues without having to open every issue and see if there was some activity other than the milestone change.
You are doing the work, so it is your preference that should get double weight.
Correct. The different names (without version numbers) for wishlist and optional means that they have the same purpose regardless of the current target version.
This was implying that the new milestone would start with only the single core feature being transferred from wishlist or optional. It was also a too oblique reference to the absence of an influence issue to be transferred.

It was not meant to imply that other items could not move as well, but any move would be significant and indicate a change in status (and timestamp) of that particular issue.

Ah yes, sure, right. That's why I discarded any ideas trying to achieve a mandatory/optional/postpone categorization with labels - wouldn't have solved anything.
Oh... ok, of course. If renaming a milestone changes the timestamp of issues/PRs assigned to it, forget everything I said. My reasoning is based on the assumption that milestone renaming does not change timestamps.
Ok, I understand. I'd handle cases like this as "optional" too, something that can go in, but isn't required. Unless we decide that incorporating the fully functional battle simulator into master will postpone the release too much, in which case the battle simulator would be assigned to the "post" milestone.
Well, not having all the issues/PRs their timestamps reset (which, as you pointed out, isn't exactly helpful when trying to work through the issues/PR list) certainly takes precedence over my personal tastes.
Ah yes, that makes sense.

Well, we can adjust the workflow according to your suggestion after the release (won't be of any use before I guess): create a milestone "vX.Y.Z" (or "next release" if the version number of the next release hasn't been decided yet) and move all issues/PRs that are mandatory for the next release to it. Then have two milestones, "optional" and "postponed", which won't change with releases. By default issues and PRs are assigned to "optional", unless they are deemed mandatory of course. Then move issues/PRs between "optional" and "vX.Y.Z"/"next release" as required. Once we get close enough to a release that having to postpone issues/PRs becomes necessary, move the respective issues/PRs to "postponed". Issues/PRs that are assigned to "optional" and get resolved/merged have to be moved to "vX.Y.Z"/"next milestone" with this new scheme of course.

Once a release is out:

• Close the corresponding "vX.Y.Z" milestone.
• Create a new "vX.Y.Z+1"/"next milestone" issue.
• Either create new issues/PRs for the essential/mandatory features for the next release and assign them to "v.X.Y.Z+1"/"next release", or, if they already exists, move them to "v.X.Y.Z+1"/"next release". Those already existing issues/PRs can come from both "optional" or "postponed" of course.
• Move everything left in "postponed" back to "optional".

Sounds reasonable? Any comments, anyone?

Status update: as those of you following the discussion in the Refining the Imperial Stockpile thread (has been the "Playtesting feedback on Imperial Stockpile" thread before, I renamed and moved it to Top Priority Game Design because it actually is far more of a full blown design discussion than merely a playtesting feedback) have most likely realized, the new Imperial Stockpile feature needs some serious refining before it can be deemed ready for release. Which means we will not be able to meet the January/February deadline. It's really hard to say how much more time this is going to take, my guess is maybe 2-3 more months, which means coming April/May.

@LGM-Doyle, @Geoff, bump? #1732 has been resolved in the meantime, but #1897 is still open... so should that issue be considered release blocking, or should we consider it only optional for the release?

Hostless mode is rather niche and entirely optional, so I don't have a problem considering it experimental and leaving it incomplete / buggy in a release.

Ok, reassigned #1897 to "v0.4.7 (optional)".