Closed
Description
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?
Metadata
Metadata
Assignees
Labels
No labels
Activity
waynzh commentedon Nov 30, 2024
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
oreslint-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 commentedon Dec 11, 2024
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 commentedon Dec 19, 2024
fwiw we use
semantic-release
over ateslint-plugin-jest
and co - landed commits are formatted following conventional commits, which in turnsemantic-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 commentedon Jan 3, 2025
Thanks for sharing this @G-Rath! However, I think
changesets
and its somewhat more manual approach is better suited for eslint-plugin-vue thansemantic-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 commentedon Jan 13, 2025
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 ofeslint-plugin-jest
, is there a minor/patch release for each merge? If so, it may not suit our operation.G-Rath commentedon Jan 13, 2025
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 arefix
,feat
, andperf
, 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.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 commentedon Jan 14, 2025
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 commentedon Mar 5, 2025
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.
.eslintrc
configs name changes #2700ota-meshi commentedon May 14, 2025
@waynzh @FloEdelmann I've introduced Changesets to this repository!
There might still be some things that aren't working properly, but you should be able to release this plugin now!