Non-backported issues + multiple long-running lines = ugh

[bitprophet]

Scenario

This kind of picks up from / relates to #17: in that scenario, there were some "active" release lines, then some older inactive ones, and a bug was kinda "shoved down" into the older inactive lines as a one-time thing, which meant cutting some new releases for it. #17's solution of explicit releases solves that fine.

What it does NOT solve is the scenario where you have, say, 2-3 active release lines for a longish period of time (like how I currently try to backport stuff to Paramiko 1.10, 1.11, and 1.12) and a non-major, but also non-backportable (because it fixes a newer feature) bug pops up.

E.g. in my specific case, a feature got introduced in 1.11.0, then it got a bugfix in 1.11.2. The 1.10.x line is still active, but this bugfix did not appear in it as it didn't apply. However, the current rules mean that we assume it WAS backported, so it appears in any 1.10.x releases, which is bad.

Even if I stop supporting 1.10 now, that means I have about 3-4 1.10.x releases that have to be converted to explicit releases (annoying) and if I want to keep supporting it, that annoyance will keep scaling.

Solutions/thoughts

• Allow marking bugs as e.g. "1.11+" and do some basic version math to determine which line buckets they should appear in. Think I had this idea during #17 but because #17's use case was kind of the inverse, it didn't pan out. But it might work here.
• Subversion of above, state ALL release lines it should be in, since the number of these is usually small & we're only indicating it on a handful of non-backported bugs ever. E.g. "1.11, 1.12".
  • Counterpoint: then we have to go back and update those anytime we add new release lines. Not really maintainable.
• Suck it up and just leverage explicit release lists. Boooooo.
• ???

[bitprophet]

One issue in implementation is the formatting. Instinct is to use yet-another-keyword-like-thing, e.g.:

* :bug:`35 1.11` This is a bug.

to note bug number 35 exists in versions 1.11 on up.

However, look at how hard that is to read; the numbers kinda mesh together.

I think a more verbose and more natural to read/write format might be better, given that this is still intended to be a minority use case. E.g.:

* :bug:`35 (1.11+)` This is a bug.

---

As usual this makes me wish for an easier spot to stick metadata. Wonder if it's feasible at this point to factor metadata into another role that (unlike bug etc) doesn't turn into any output and is purely a hint. E.g.:

* :bug:`35` :meta:`1.11` This is a bug.

Or even:

* :bug:`35` This is a bug. :meta:`1.11+`
* :bug:`37` This is another bug :meta:`major`

[bitprophet]

Gonna try going with the "verbose but still inline" approach for now, no time for trying a 2nd role, can always iterate.

Also, was thinking this could replace the need for explicit releases, but now I realize that is not the case - there is some overlap but only in very minimal/contrived situations.