-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change Request: release-please
should create release only for certain tags
#18455
Comments
release-please
should create release only for certain tags
I don't think we need I also don't think |
Okay, so to summarize, only these three tags would trigger a release:
We'd continue using tags as before, with an exception: If we think that a change should trigger a release, but the tag we usually use for that kind of change is not one of the three above, we'd tag it as Does this sound good? |
Sound good to me. @fasttime what do you think? |
Sounds good! Just to state the obvious, the tags will be the same for breaking changes as well (I think I've only seen |
seems all the linked PRs have been merged. so, closing. |
ESLint version
N/A
What problem do you want to solve?
Currently, in all repositories where we use
release-please
, it's configured to generate/update the release PR on any commit we push to the main branch, regardless of the commit tag.The commit tags we're using are:
build
chore
ci
docs
feat
fix
perf
refactor
test
The problem is that not all kinds of commits warrant releasing a new version of the package. For example, if the only change we made since the last release was adding more tests, releasing a new version of the package does not benefit anyone. When deciding which packages to publish, we always need to review the commit list for each. It would be much easier for us if
release-please
would be generating release PRs only when there's a change we'd like to release.What do you think is the correct solution?
Configure
release-please
to generate/update release PRs only for certain commit tags and review our policies for choosing tags for particular changes.The tags that I believe we would certainly like to release a new version of the package for are:
docs
- to update README on npmfeat
fix
perf
Then, there are changes that shouldn't be observable to end users but are affecting (or may affect) production code so we might want to release a new version to see if there are any issues as early as possible:
build
refactor
The tags that I believe we would not like to release a new version of the package for are:
ci
test
So above are 6 tags that I think
release-please
should generate/update the release PR for, and 2 tags that I don't think it should.The remaining one is
chore
.Per our policies,
chore
should be used "for changes that aren’t user-facing". Like, for example, fixing a typo in a test file. So, by the definition, these changes shouldn't warrant a new release.But so far we have used this tag for changes that are user-facing, notably:
refactor
.chore
for these changes or maybe introduce a new tag.Participation
Additional comments
No response
The text was updated successfully, but these errors were encountered: