Release automation

[ota-meshi]

Currently, I manually release this package.
I didn't change the release flow in the hope that it would be easy for the previous maintainer to go back.
But now that we have new maintainers, I think it's time to rethink the release flow.
I don't have any preference on how to automate it.
@FloEdelmann @waynzh Can you give me your opinion/preference?

[waynzh]

I don't have much experience regarding automated releases. I noticed that typescript-eslint automatically publishes minor versions every Monday through an action from a private repository.

However I don't think our update frequency necessitates that. Perhaps we could consider actions similar to eslint-sevlte or eslint-stylistic that generate a release changelog PR if there are changes. Manually merging or merging at a fixed time every week seems to be quite efficient for me.

[FloEdelmann]

I fully agree with @waynzh.

In other repositories like https://github.com/stylelint/stylelint, I have had good experiences as a contributor with changesets. But I have no experience with setting it up.

[G-Rath]

fwiw we use semantic-release over at eslint-plugin-jest and co - landed commits are formatted following conventional commits, which in turn semantic-release uses to build the changelog and determine what kind of release to do (patch, minor, major); that all happens automatically making releases very hands off and also means stuff is released ASAP so there's no "when will this fix be released" etc kind of stuff.

It also supports pre-releases and other stuff like that.

It tends to be my go-to for release automation and I've set it up a few times, if you'd like a hand - it would of course mean going forward you'd use conventional commits, but existing commits shouldn't cause trouble; plus if you're squashing your PRs, generally only the PR title (which gets used as the final commit message) actually needs to be formatted "conventionally".

(I was looking some stuff up and came across this, so figured I'd share my two cents from one plugin maintainer to another - thanks for all your work on this plugin, it's made my intro into Vue smoother ❤️)

[FloEdelmann]

Thanks for sharing this @G-Rath! However, I think changesets and its somewhat more manual approach is better suited for eslint-plugin-vue than semantic-release. We usually accumulate a few changes for a release, and then manually format the changelog in the GitHub release. That's only my personal opinion though 🙂

[ota-meshi]

Sorry for the late reply.

Thanks for your opinion, I'm relatively familiar with changesets since I use other OSS as well.

I don't know about semantic-release, but looking at the release of eslint-plugin-jest, is there a minor/patch release for each merge? If so, it may not suit our operation.

[G-Rath]

is there a minor/patch release for each merge?

Yup that's correct - whenever the release flow runs (which for us is part of the main CI), it looks for any commits since the last release that match a "release prefix" (which are fix, feat, and perf, if I recall correctly), and if so does a release.

For us we have that workflow running on every push to main, but you can just as easily have it be a manually triggered workflow, or only trigger when there's a change to a particular file.

We usually accumulate a few changes for a release, and then manually format the changelog in the GitHub release
...
If so, it may not suit our operation.

Respectively, I'd challenge that - the whole point of the flow (and reason why this issue was opened) is to lower the bar for releases to reduce the amount of manual work and dependency on maintainers, which releasing after every suitable PR I'd say fits the bill.

I've found as an OSS maintainer it's been a lot easier to keep on top of things for codebases using semantic-release as I know I just need to get the PR in front of me landed for it to be out the door, and so if I end up having time for just one PR that evening, it'll be completely done rather sitting around for me to next have the time to do a release.

I don't think that changesets is bad by any means though and different classes of libraries/tools are suited to different release strategies - ultimately having a release automation will be the biggest time saver 🙂

[ota-meshi]

I've found as an OSS maintainer it's been a lot easier to keep on top of things for codebases using semantic-release as I know I just need to get the PR in front of me landed for it to be out the door, and so if I end up having time for just one PR that evening, it'll be completely done rather sitting around for me to next have the time to do a release.

That's an advantage, but I think there's a trade-off for us.
We often like to release several PRs (changes) together.
For example, we do it when supporting new Vue features. e.g. https://github.com/vuejs/eslint-plugin-vue/releases/tag/v9.13.0
That work could take a few weeks, and I would rather avoid releasing them with every PR change.

[ota-meshi]

When I have some free time I'd like to work on introducing changesets.
If anyone wants to do that sooner they're welcome to work on it before me.