chore(changelog): Add script to generate release notes

[mttrbrts]

This PR adds documentation and a script for maintainers to use to automatically generate release note content from GitHub Pull Requests.

Flags

• Note that the mapping in package.json uses the lowercase version of the GitHub Labels with unicode emoji characters rather than their short-codes.

Here is a sample output for the latest unreleased changes.

---

Unreleased (2021-03-10)

✨ Enhancement

• ui-contract-editor
  • #277 style(ui-contract-editor): Drag-Drop Handle Resize - I137 (@K-Kumar-01)
  • #250 feat(ui-contract-editor):drag&drop disabled for embeded clauses (@sanketshevkar)
• storybook, ui-components, ui-concerto, ui-contract-editor, ui-markdown-editor
  • #247 feat(package): add repository information to package.json (@Aniruddha-Shriwant)
• ui-markdown-editor
  • #237 feat(ui-markdown-editor): center align h1 tags - I146 (@Udbhavbisarya23)
  • #225 style(ui-markdown-editor): remove link modal fade-in effect - I218 (@K-Kumar-01)
• storybook, ui-markdown-editor
  • #229 style(ui-markdown-editor): resolve toolbar icon shrinkage - I228 (@K-Kumar-01)

🐛 Bug

• ui-markdown-editor
  • #283 fix(ui-markdown-editor): styleblock refresh - Styles block not updating as we move our cursor #276 (@d-e-v-esh)
  • #268 bug(ui-contract-editor): remove z-index of toolbar - I87 (@Udbhavbisarya23)
  • #252 fix(ui-markdown-editor):multi-para to list proper indent - I158 (@K-Kumar-01)
  • #258 fix(ui-markdown-editor): list formatting is preserved in headings (@gatij10)
  • #222 fix(ui-markdown-editor): resolve hyperlink overflow - I219 (@K-Kumar-01)
• ui-contract-editor
  • #251 fix(ui-contract-editor): Highlight read-only text clause template - i242 (@K-Kumar-01)
  • #240 fix(ui-contract-editor) prevent sig variable edits on readOnly - I212 (@sanketshevkar)
  • #231 fix(ui-contract-editor): prevent clause drag and drop in list - I157 (@sanketshevkar)
  • #236 fix(ui-contract-editor): adjust tooltip z-index - I185 (@K-Kumar-01)
• ui-components
  • Long clause template names intersect with template logo (@Michael-Grover)

🧼 Chore

• storybook, ui-concerto
  • #273 feat(ui-concerto): Upgrade to Concerto v1.0 (@mttrbrts)

Committers: 8

• Aniruddha Shriwant (@Aniruddha-Shriwant)
• Gatij Taranekar (@gatij10)
• Kushal Kumar (@K-Kumar-01)
• Matt Roberts (@mttrbrts)
• Michael Grover (@Michael-Grover)
• Sanket Shevkar (@sanketshevkar)
• @Udbhavbisarya23
• @d-e-v-esh

[irmerk]

Some questions...

[irmerk]

So it looks like we should maybe do a more comprehensive mapping of our labels to match what is in our current releases (that relate to web-components)?

[mttrbrts]

I found that in cases where multiple labels have been applied, this tool adds the PR in multiple places.

Personally, I also find the difference between a "Feature Request", "Enhancement" and "Styling" to be too subtle for a release note.

Also, "Feature Request" specifically doesn't make much sense as a category for a release note.

[mttrbrts]

BTW, I also tried mapping "Feature Request" and "Styling" labels to ":sparkles: Enhancement" but that leads to a bug in the tool where we end up with 3 copies of the "Enhancement" section and the "Feature request" and "Styling" PRs are lost.

[irmerk]

Well I think Type: Feature Request 🛍️ would be 🚀 New Feature.

So actually, what happens to merged PRs that are Type: Feature Request 🛍️ right now? Are they not included?

[mttrbrts]

So actually, what happens to merged PRs that are Type: Feature Request 🛍️ right now? Are they not included?

That's right, they get ignored.

What's the difference between Type: Enhancement ✨ , Type: Feature Request 🛍️ (as a GitHub label ) and 🚀 New Feature ?

[irmerk]

Type: Enhancement ✨ and Type: Feature Request 🛍️ are labels for PRs and Issues, 🚀 New Feature is a tag in the release note. More PRs are tagged Type: Feature Request 🛍️ than Type: Enhancement ✨, so we don't want to be ignoring those.

[mttrbrts]

Let me rephrase...

In a release note, personally, I wouldn't expect a category called "Feature Request". By the time that it gets to that stage, the change is a feature (or an enhancement). I agree that "Feature Request" makes sense as a label for issues, but less so for PRs.

In that context, we shouldn't retain both and map them to the same 🚀 New Feature section in a release note because of the bug that I mentioned in lerna-changelog. We can only have unique targets in the mapping.

So my proposal is to not use the label Type: Feature Request 🛍️ for PRs and instead use Type: Enhancement ✨. An alternative would be to also label every PR that has Type: Feature Request 🛍️ with Type: Enhancement ✨ (because the former would be ignored)

[irmerk]

Okay yeah this makes sense. So Issues => Type: Feature Request 🛍️, PRs => Type: Enhancement ✨.

Could you as a next step update https://github.com/accordproject/web-components/wiki to have the Release Workflow Guide to not point to techdocs and rather fork that information and update it with what this PR changes? We'll want to have something definitive for maintainers to reference when both creating a release note and also labeling PRs.

[DianaLease]

This is awesome!