Allow issues to appear in multiple sections

[eleftherias]

The flag is releasenotes.issues.allow-in-multiple-sections.

[wilkinsona]

Thanks, @eleftherias. I wonder if we can come up with a name for the flag that's more informative than allowDuplicates. The current name doesn't convey to me that it would allow an issue to appear in more than one section. Also, duplicate is a bit of an overloaded term when talking about issues.

With one eye on #36, I wonder if we should introduce a new issues section in the YAML that's a peer of sections. The flag proposed here could then be named something like allow-in-multiple-sections. That would leave the YAML looking something like this:

releasenotes:
  github:
    username: testuser
    password: testpass
    organization: testorg
    repository: testrepo
  sections:
   - title: "New Features"
     emoji: ":star:"
     labels: ["enhancement"]
   …
  issues:
    allow-in-multiple-sections: true

[eleftherias]

Thanks @wilkinsona. I have updated the commit to use the flag releasenotes.issues.allow-in-multiple-sections.

[wilkinsona]

Thanks, @eleftherias. #39 prompted me to think about this a bit more. Just out of curiosity, how do you intend to title issues that will appear in multiple sections? It seems quite hard to me to come up with a title that suits multiple categories.

[eleftherias]

@wilkinsona The use case for Spring Security is to have a section that calls out any non-passive changes.
These are usually bug reports, so we would like them to appear in the "Bug Fixes" section as well.
We don't have a different naming scheme for these types of issue titles.

[eleftherias]

@wilkinsona Expanding on my previous comment, what we've done in the past is to keep the original bug report title, for example "SwitchUserFilter vulnerable to CSRF".
The idea is that users can refer to the associated commit and see the non-passive change. We have also been adding a comment to the issue that describes the non-passive change.

I can see the argument for having a title that describes what the non-passive behaviour is, for example "SwitchUserFilter will no longer match any request, but instead will only match POST".

However, I favour using a title that describes why the change was made, rather than what the change is.
I think this approach also makes an issue easier to understand if a user arrives to the issue from somewhere other than the release notes.

This is just an opinion based on our use case. I'm not sure how well it would apply to the suggested sections mentioned in #39, such as "Removal".

[philwebb]

Thanks for the PR!

I've tweaked things a bit in 6fe2e6e by introducing the concept of a section group. The idea is that you can now create groups that define how issues are duplicated and distributed across sections.

For the Spring Security use-case you can define the "Non-passive" section like this and I think it'll do what you want:

changelog:
  sections:
  - title: ":rewind: Non-passive"
    group: "nonpassive"
    labels: ["non-passive"]
  - title: ":star: New Features"
    labels: ["new"]
  - title: ":beetle: Bug Fixes"
    labels: ["bug"]