"Delayed bugfix" ordering problem

[bitprophet]

Ran into this error output in Fabric, e.g. this changelog (n.b. probably was an issue before then but that link is at time of debugging).

Seems to be the following:

• Time starts, let's say 1.0.0
• Bugfix committed (this is the problem child) - let's say bug 1
• Feature commited
• Feature release occurs (this flushes/empties the 'unreleased' list), 1.1.0
• More issues are committed (this adds more items to 'unreleased')
• Bugfix release occurs for the previous release line (the one w/ bug 1 in it), aka 1.0.1
• Kaboom: the attempt to say "ok, these guys are releasing, let me remove them from 'unreleased'" dies because 'unreleased' was cleared out before bug 1 was printed out in the changelog.

How to interpret this?

• Our docs (which I just wrote out explicitly recently, see #15) state that feature releases implicitly include prior bugfixes/bugfix release contents. So in this case, release 1.1.0 would be presumed to include bug 1.
• However, the distinction of "bugfix" vs "bugfix release" is important - in this case the maintainer failed to do the normal thing, namely to put out a bugfix along with the feature release. But they probably did do a merge and so bug 1 probably did get released in 1.1.0.
• Because of how 'unreleased' works, somebody reading the changelog after 1.1.0 went out and before 1.0.1 went out would not see bug 1 anywhere in the list (whereas he would show up under 'unreleased' prior to 1.1.0's release.)
• And after 1.0.1 is added, it "looks like" bug 1 was merged after 1.1.0's release (and so one might assume, wrongly, that 1.1.1 includes it when it comes out.)

How to solve it?

• Probably best to tease out 'unreleased' into bug and feature editions, so that in the above scenario, the 1.1.0 feature release would have "flushed" unreleased features but not unreleased bugfixes. Will experiment.

[bitprophet]

Well, teasing things out seems to have worked, except there's another case hiding after it:

• Bugfix goes into unreleased_bugfix + each release line - say 1.1 and 1.2
• 1.1.x bugfix release goes out, removing bugfix from the unreleased_bugfix and 1.1 buckets, leaving it in the 1.2 bucket
• 1.2.x bugfix release goes out, sees bugfix in the 1.2 bucket, tries removing from unreleased_bugfix, but it's no longer there, boom.

This seems to expose another unforeseen problem w/ 'unreleased' releases, which is: should they contain bugs/etc which have never been released, or ones which haven't been released everywhere they're slated to be?

The former feels more intuitive and correct to me; the latter isn't terrifically useful unless you're in that (usually small or nonexistent) temporal window between two/more releases both containing the same bugfix, and you are concerned about knowing if the bug in question is actually going to come out in the latter release (e.g. you see it in 1.1.3 but want to know if it'll still appear in 1.2.1 too).

What this means is...probably just to skip over this error (i.e. "remove() only if item is in the list"). Which also means I could probably have just done that in the first place. Will look at real output of the new split unreleased stuff and see if it feels worth keeping in, otherwise will revert earlier fix too.

[bitprophet]

Looks OK, leaving new changes in, and fixed this 2nd case.