-
Notifications
You must be signed in to change notification settings - Fork 31
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
Provide a way to override the behavior of major commit messages for pre-1.0.0 versions #204
Labels
Comments
My workaround for now:
|
The way I see this working would be an optional parameter to |
ajoberstar
added a commit
that referenced
this issue
Nov 24, 2024
As reported in #204, I had unfortunately forced the preference to not allow commit messages to bump to v1 on all users of commit message scope calculators. In theory, I had meant to allow custom parsing, but the custom parsing still enforced the pre-1.0 special casing. The new approach implements a new ofCommitMessageParser() mechanism that has the parsing function accept both the commit message and a boolean indicating whether the project is pre-v1.0.0. This allows the user full control of the approach they want to use. To simplify adoption of this new capability the default commit message parser was enhanced to allow "major!: subject" prefixes that bypass the pre-1.0.0 check, allowing a more CD style bump to 1.0.0. Fixes #204
Planning to release soon and you'll have two options:
|
Thanks for changing this, though I have switched to
https://github.com/jmongard/Git.SemVersioning.Gradle to get true
conventional commits and changelog generation
…On Sat, Nov 23, 2024, 8:58 PM Andrew Oberstar ***@***.***> wrote:
Planning to release soon and you'll have two options:
- Use the existing calcScopeFromCommitMessages() which now allows a major!:
My message prefix to force a 1.0.0 bump
- Use calcScopeFromCommitMessageParser(...) with a custom parser of
the form (String commitMessage, boolean preV1) -> Optional<Scope>
—
Reply to this email directly, view it on GitHub
<#204 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACUPTTLLH7I2ESJKG43I6D2CEXCXAVCNFSM6AAAAABPZPYDLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVG42DSOBTGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I understand the reasoning for that but, that puts me in a catch-22 that I have no good way to promote a library to 1.0.0 status. The docs say that:
But that assumes that the developer is releasing and pushing things to the repo directly. In good development practice pushing directly to a main branch is forbidden and the only way to change main is via pull requests that are built in a CI/CD build.
The question then is how can one then through a pull request move the library to 1.0.0? The only way I can see is to do a PR that forces scope to major, merge it, do another PR that undoes the forcing of scope and merge that. That is not a good developer experience. There should be an option to disable the pre-1.0.0 behavior or perhaps set a minimum version
The text was updated successfully, but these errors were encountered: