When poking around exposing a parsed changelog programmatically (so folks could e.g. figure out whether the changelog needs updating with a release entry at release time) I realized there's data left in the line manager which we don't expose in the finally published changelog.
For example, consider a project with multiple active bugfix lines, say a 1.10 and 1.11, and assume most/all bugs are backported to 1.10.
When it comes time to release, one will go back to 1.10, add a release line to the changelog (and tag and publish and etc etc). At that point in time, everything's great - all bugs are in the new 1.10 release (say 1.10.5), no bugs are in 'unreleased 1.x bugfix', etc.
Now switch to the 1.11 branch, and merge in the 1.10 branch. Problem: even though no 1.11 release line is in the changelog, the 'unreleased 1.x bugfix' "release" is still empty/nonexistent when you render/parse the changelog - because those bugs are now in a release (1.10.5). Even though, from the perspective of 1.11, they are still outstanding/pending/etc.
Now, the internal LineManager object knows this - its [1]['1.11'] release-line bucket is non-empty at end of run. And if one adds an eg 1.11.3 release line, it empties that bucket as one would expect. But we're never exposing that bucket to the rendered changelog.
What this means:
"Unreleased" is narrowly/strictly defined right now, it's 100% literal: did an issue appear in any releases at all?
In some cases, users may expect different behavior: has an issue been "fully" released into all lines for which it is eligible? (Aka: is it out of all pending buckets?)
This may mean we want to expand the visual display of 'unreleased' issues so they include non-empty per-line buckets, and not just the 'unreleased' buckets. (I'm not positive, though, thus why this is a "Consider" ticket...)
The programmatic use case noted up top (which didn't get its own ticket, but will be released shortly) does still want access to this info, but it can be served by simply ensuring we publish both the line manager and the artifact/resulting changelog object/dict. Then users can go "hey, I'm on branch 1.11, but the 1.11 bucket is non-empty - I need to cut a release".
When poking around exposing a parsed changelog programmatically (so folks could e.g. figure out whether the changelog needs updating with a release entry at release time) I realized there's data left in the line manager which we don't expose in the finally published changelog.
For example, consider a project with multiple active bugfix lines, say a 1.10 and 1.11, and assume most/all bugs are backported to 1.10.
When it comes time to release, one will go back to 1.10, add a release line to the changelog (and tag and publish and etc etc). At that point in time, everything's great - all bugs are in the new 1.10 release (say 1.10.5), no bugs are in 'unreleased 1.x bugfix', etc.
Now switch to the 1.11 branch, and merge in the 1.10 branch. Problem: even though no 1.11 release line is in the changelog, the 'unreleased 1.x bugfix' "release" is still empty/nonexistent when you render/parse the changelog - because those bugs are now in a release (1.10.5). Even though, from the perspective of 1.11, they are still outstanding/pending/etc.
Now, the internal LineManager object knows this - its
[1]['1.11']release-line bucket is non-empty at end of run. And if one adds an eg 1.11.3 release line, it empties that bucket as one would expect. But we're never exposing that bucket to the rendered changelog.What this means:
1.11, but the1.11bucket is non-empty - I need to cut a release".