Improving automation around releases

[atuttle]

Currently 👎🏻

As we accept PR's and make improvements...

We document changes in @atuttle/TaffyDocs by creating a file for the new version and adding documentation for the changes in that file.

• Sometimes we ask the PR submitter to create this file (by copying the latest version and renaming it).
• This is because the Taffy Docs allow you to view documentation for each released version of Taffy.
• Currently, I indicate what that file name should be based on what I expect the next version number to be. Sometimes the version number needs to change between the time someone makes one addition and the time someone makes another change. (e.g. the first change would become 4.0.1 and after the next revision it would be 4.1.0, based on everything that's changed so far). This isn't great.
  • A better approach would be to name the file something like @next.md or just next.md if the @ symbol isn't allowed. Then it could be renamed to the appropriate version number at the moment of release (by an automated process! 😱), and a new @next.md could be created with the applicable contents.

Eventually, I decide it's time for a release

Truth be told, this doesn't happen as often as I would like, because of all of this friction! More automation will beget more releases.

• Tag the code with the updated version number (per Semver)
• Update the [TaffyDocs readme.md]() to add a link to the new version's docs file.
• Find and list all of the changes since the last release in the release notes at the bottom of the docs for the new version. This is the most laborious part of the whole process...
  • Usually this involves looking at the commit history since the last tag, and using it to identify PR's and committer-commits, and trying to write something reasonably consistent and grateful in the docs, ala this
  • I've dabbled with some release automations, but never had enough time to finish setting that up. I would be quite happy to alter the current format of what gets appended to the end of the docs for each release if it could be auto-generated!
  • I don't think we're going to switch to conventional commits or semantic release unless someone wants to spend some time explaining the migration path to me. Both seem great but I don't fully comprehend what to do if you didn't start with those patterns from day 1. Schooling is welcome, though. :)
  • ... however, this is supposed to create release notes automatically, including indication of breaking changes, and doesn't require anything in the way of specific commit message formatting (it uses PR labels instead). Color me interested.

---

A Healthy Future 👍🏻

So basically, if someone were to submit a PR that implemented both of these automations for this repo in a useful way, you'd be my personal hero. 💝 Bonus points if it can also submit a PR to @atuttle/TaffyDocs that renames @next.md to {new_version}.md, links it from readme.md, and creates a new @next.md. Of course we can discuss the particulars of all of this in public or in private if anyone is interested in tackling any or all of this.

(And should we consider moving the docs into this repo? That would make it easier for people to include docs updates with their code changes, and probably make the docs-update-automation easier, too! 🤔)

[atuttle]

I've just figured out how to add a github action that enforces the use of the Semver-Major/Minor/Patch labels here in the repo, which would not only make it easier when combing through the docs to manually compile release notes, but are what the auto-generated release notes would use, too. 👍🏻

[atuttle]

Aaaaand I couldn't get it out of my brain and just did it myself. I think I covered everything in this issue. 🚀