Add support for arbitrary issue types

[Vye]

I use releases for a GUI app. I find myself making improvements to the UI that are not bug fixes but more cosmetic changes that improve readability or something similar. I don't feel right labeling them as features or support issues either.

Do you think the addition of a cosmetic issue type would make sense?

[bitprophet]

Personally I put that sort of change under either Feature or Support, depending on how I feel about it at the time.

You're not wrong though, it'd probably be nice to have another category (or really, to organize things so there can be arbitrary categories). Main thing is each new category would need to be slotted into the 'bugfix or feature release?' dichotomy, which really just becomes a "minor or major change" sort of thing.

[kyrias]

A stop-gap solution could be just adding major and minor roles that work like feature and bug, respectively

[jstoiko]

Some issues/PRs are neither bugs, features, nor support. I like the 'cosmetic' issue type idea. However I feel like adding another type might not fit all cases. What would be nice is a way to not specify a type at all.

E.g.

* :release:`0.1.2 <YYYY-MM-DD>`
* `` Minor change that I felt should be part of a minor release

Currently, it will turn the 2nd line into a "bug".

[bitprophet]

@jstoiko Problem is, that sort of "minimum data" line item is already shorthand for a bug (as you saw) which is an on-purpose, requested-feature behavior - so changing it would break that :(

To the greater point of having "unclassified" line items, though, that's not a bad idea. There is already a generic Sphinx role in Releases called :issue:, but it's currently intended for use within line-item descriptions to help make easy Github Issue links. (See the 2nd line item, bug 194, here: https://raw.githubusercontent.com/paramiko/paramiko/2576b16b5439fd3487e498c21203593e10dbee52/sites/www/changelog.rst - it references "related issues" internally. Rendered is at http://paramiko.org/changelog.html - search for '194'.)

So what might work is to make sure Releases can consume those as "top level" line items, and when it sees them, it just omits the styled [type here] prefix, e.g.:

* :bug:`1` an bug
* :feature:`2` an feature
* :issue:`3` something cosmetic or whatnot
* :bug:`4` another bug

There's a couple minor downsides to this, however:

• Having truly unclassified/non-prefixed issues feels odd, visually/conceptually, and it might confuse some readers.
  • That's why I may still prefer the "add more issue types or make them configurable" approach.
• The intersection of "unclassified changelog entry" and "entry with no matching Github Issue" might be poorly defined, I'd have to revisit how we implemented the bit where one can use - as the "issue number".
  • If that can work without feeling clunky, though, it would still work well visually, becoming basically just a regular old bullet line-item with no other special formatting.

[bitprophet]

Updated topic to be more descriptive.

Another need I thought of the other day is for a "security" type. Would be nice to add that to the built-ins, but of course, it's also strong fodder for "let people designate whatever labels they want".

[jstoiko]

"let people designate whatever labels they want"

Yea, I'm a big fan of that. Another use case I'm thinking of is "tests". Say we added more coverage and we want our community to know: "Test coverage now 100%" or "Tests now use this amazing new library".

[bitprophet]

I usually stick that under Support, but again, +1 on the arbitrary labels idea.

I just had to do a lot of tweaking of the "how issues behave re: release rollup" for the 1.1 release and it definitely got me thinking about this again. Probably not suuuuper hard to implement at this point, mostly the "is it bug-like or is it feature-like" stuff needs additional centralizing first (but see also #50 which is kinda required & backwards incompat. I think "arbitrary labels" would make sense for a backward incompat 2.0 anyways.)

[spaceone]

I need a security type. Also refactor would be nice, too.