Move away from strict/automatic semantic release

[lwasser]

The current circle ci build deployment uses a strict semantic versioning approach, which is applied automatically. That is why conventional commits have been important. I'm happy using conventional commits to maintain a readable commit history!

But I don't like using them for semantic releases, as so many contributors don't think about commit messages even tho they submit great contributions. I'd rather us create a workflow where we release periodically using a human-triggered deployment. This also avoids a bad pr being merged by mistake and a deployment happening automatically that infects someone's machine.

I'd love feedback from others on moving away semantic releases and to a GitHub Actions-based workflow and toward a GitHub Actions-based workflow with a protected environment where only a few maintainers can trigger a deploy. (and a human makes the final "ok" to do so)

[lwasser]

To add to this now, i'd prefer a release workflow that

1. A human triggers a release, not an action. I prefer this for security reasons, as an automatic release trigger would mean that if a potential bad actor somehow was able to slip a commit into main via a large pr then a release would happen before we could even check it. This happened a year or two ago and really made me appreciate a human-centric release workflow
2. I'd love to create a release-based workflow where a release triggers a new build and a human approves it on GitHub.
3. I'm fine with encouraging conventional commits, however, as we squash-merge because I think that makes a nice clean commit history that is easier for a human to parse!!

I don't know if semantic release is the tool that supports automatic releases, but if it is, let's drop it - ONLY IF you all agree with this - I'm open to other opinions. Releases are one place where I'm quite opinionated, but I value the team more than my opinion always so let's chat first.

cc: @JoshuaKGoldberg @JimMadge ✨

[jdalrymple]

Have you guys thought about using changesets? Basically you define the "change" you want to be deployed separate from the commit message structure itself? I personally find it a bit of extra work haha, and so ive made some modifications for my own repos to actually pull the type of change from the PR label instead, but its a nifty tool and actively developed

[JoshuaKGoldberg]

I'm a big fan of both changesets and release-please for manual releases.

• Changesets: what I use on https://github.com/bingo-js/bingo and https://github.com/flint-fyi/flint.
• release-it: @michaelfaith has set up the latter on a few repositories we co-maintain: https://github.com/JoshuaKGoldberg/eslint-fix-utils, https://github.com/JoshuaKGoldberg/eslint-plugin-package-json, https://github.com/JoshuaKGoldberg/package-json-validator

IME both are pretty customizable and pleasant to use. I don't have a preference either way for all-contributors.

I'm fine with encouraging conventional commits, however, as we squash-merge because I think that makes a nice clean commit history that is easier for a human to parse!!

Oh, and: +1 from me on this 🙂

[michaelfaith]

Similar to @JoshuaKGoldberg both Changesets and Release Please are great options. For open source use cases, I slightly lean towards Release Please (and especially for repos that have already had a practice of using conventional commits format), since contributors and maintainers wouldn't need to change the way they've been working already. If you squash commits at PR time, then the burden of getting the format right would really just land on the maintainer's shoulders (via the PR title). With Changesets, that burden is shifted to the contributors to create the changeset entry. I think that's fine and works ok if most of the people contributing to a project are internal or affiliated with the project. If there's a large external contributor pool, shifting that burden to them adds additional friction to the contribution process that I'm not super comfortable with.

[JimMadge]

I am also guilty of forgetting to use the commit convention 😆. Also, I find the flow a bit awkward, git-cz doesn't fit very well in the way I tend to work.

I've used changesets on another project and they seem quite nice. Less burden on contributors. One changeset per PR rather than multiple formatted commits. It seems to generate sensible draft release notes which are a great starting point too.

They have a required workflow which just checks there is a valid changeset, which is a nice nudge to make one.

[JimMadge]

I think this is a semantic point, but I do like semantic versions, so I think we should keep that. Makes dependency management much easier. It feels like a polite thing to do for your users.

[lwasser]

What a great discussion! Reading all of the comments here, I really like @michaelfaith overview above which suggests that release please might be a gentler way to automate the changelog.

If you squash commits at PR time, then the burden of getting the format right would really just land on the maintainer's shoulders (via the PR title).

We've found in stravalib that people always forget (including myself) to update the changelog). So if there is a way to automate that piece, i'm all for it. I looked into it the other night and it looks super awesome!! It seems like we can then decide when we're ready to merge the release pr and cut a new release.

I also have seen even in this repo that conventional commits are difficult to ask contributors to follow. So id rather reduce friction for contributors as we have a lot of them here which is awesome!

So what about we test out release please to manage a (new) to this repo changelog. It is a github action setup.
We can continue to follow semver for versioning and then use conventional commits for commits.

One note about this path forward, if we all agree:

It will be important when we have open pr's that we pay attention to the title of the PR. Because when it gets squashed and merged, titles that don't have the conventional commit annotations will muddy the commit history and will potentially confuse a tool like like release please. I'd also prefer a clean commit history if we are squashing, if you are all ok with that. You can see an example below where a pr was merged but the title wasn't updated to be a conventional commit message.

Please let me know what you all think. I am super excited to set this up and i'll take on this issue if we are all onboard with this approach.

[michaelfaith]

If it's helpful, here's an example of a recent release pr: michaelfaith/eslint-plugin-package-json#1514

And the corresponding GH release it created after merge: https://github.com/JoshuaKGoldberg/eslint-plugin-package-json/releases/tag/v0.88.2

On a different repo, we also have prereleases publishing from a beta branch: michaelfaith/package-json-validator#674

[lwasser]

Thank you!! That is super helpful to see it in action!

[lwasser]

Update: I set up the release, please, in #443, and also tested it out in my fork!