Support "only backported so far" for bugfix/backported issues

[bitprophet]

Scenario:

• Fabric has a bunch of semi-open release lines, e.g 1.5 -> 1.8.
• Some bugfixes get backported only as far as is easy/appropriate, e.g. to 1.7, and when releasing just 1.7/1.8 bugfixes, no problem.
• A serious bug is found going back to 1.5; decision is made to put out bugfixes for 1.5 onwards.
• Now the changelog thinks all the 1.7/1.8 bugfixes were backported to 1.5/1.6, when they were not.

Solutions:

• Never release old stuff. Ehhhh. Not possible, esp given some things are bugfixes to recent new features. I might want to support 1.7/1.8/1.9, issue bugfix to a 1.8 feature, and that should never show up in 1.7.
• Add more annotations (as per TODO item) so I can say "this went back to X".
  • Problem with this is it approaches the "manually note down version control branch info" scenario I was hoping to avoid with all this fancy automagic bullshit.
  • I.e. now every single bugfix or backported feature/support has to note down, at minimum, the oldest branch/line it was backported to.
  • And it's error-prone, anytime you forget this notation and then release an older-than-average bugfix release, poof, extra stuff.
  • Counterarguments: it's not like a single line number is a lot of extra data; and it's not like the existing annotations (major/backported) aren't also error prone. Also...there's really no other option here that I can think of.

[bitprophet]

Got this implemented for bugs, then when trying it out in Fabric's changelog promptly realized I'm an idiot; the problem here is that I want one specific bug backported & all the other bugs to be not backported (as far).

So even though the gateway bug going back to 1.5 is the 'uncommon' case, the way I thought about this was the inverse. With this as-is I'd need to mark almost all bugs with e.g. 1.7 or 1.8 to prevent them from showing up in a 1.5.x release. I actually mentioned this above but somehow glossed over/forgot about it in the counterargument.

Also - noticed that it looks fugly as is, e.g. (n.b. using :bg not 'bug' because github emoji) :bg:\23 1.7- all numbers, hard to scan in a way that e.g.`:bg:`23 backportedis not. What'd be better is e.g.:bg:23 limit=1.7``, but that makes "add it to every bug" even worse.

---

Is there a good way to encode the "default" behavior I've been assuming? Not really - best I can think of is to do the obvious and allow decorating the release itself as being "special" and containing specific bugs. E.g. as-is, in the below 1.1.1 and 1.0.2 would both include bugs 2, 3 and 4:

* :release:`1.1.1 <date>`
* :release:`1.0.2 <date>`
* :bg:`4` yup
* :bg:`3` one moar
* :bg:`2` another boog
* :release:`1.1.0 <date>`
* :bg:`1` a boog
* :release:`1.0.0 <date>`

Could use simple comma/whitespace separation after release (esp given that while bugs have "stuff" after them, we currently ignore anything after release roles - so we can fill it in in a backwards compat fashion):

* :release:`1.1.1 <date>`
* :release:`1.0.2 <date>` 2, 3
* :bg:`4`
* :bg:`3`
* :bg:`2`
* :release:`1.1.0 <date>`
* :bg:`1`
* :release:`1.0.0 <date>`

In the above, we're explicitly saying release 1.0.2 includes bugs 2 and 3 only. Bug 4 is therefore skipped. I think this will work? Gonna give it a shot.

[bitprophet]

Have tests for this working, albeit kinda fugly and in need of some cleanup/consolidation. And expansion for edge cases, probably just skip()'d for now.

Next is to test back on Fabric and see how it works in real world usage.

[bitprophet]

Got it working!