Skip to content

Release automation #2624

Closed
Closed
@ota-meshi

Description

@ota-meshi
Member

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?

Activity

waynzh

waynzh commented on Nov 30, 2024

@waynzh
Member

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

FloEdelmann commented on Dec 11, 2024

@FloEdelmann
Member

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

G-Rath commented on Dec 19, 2024

@G-Rath
Contributor

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

FloEdelmann commented on Jan 3, 2025

@FloEdelmann
Member

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

ota-meshi commented on Jan 13, 2025

@ota-meshi
MemberAuthor

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

G-Rath commented on Jan 13, 2025

@G-Rath
Contributor

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

ota-meshi commented on Jan 14, 2025

@ota-meshi
MemberAuthor

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

ota-meshi commented on Mar 5, 2025

@ota-meshi
MemberAuthor

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.

ota-meshi

ota-meshi commented on May 14, 2025

@ota-meshi
MemberAuthor

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @FloEdelmann@G-Rath@ota-meshi@waynzh

      Issue actions

        Release automation · Issue #2624 · vuejs/eslint-plugin-vue