Skip to content
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

"next-version" as a Commit Message Action #33

Open
nickajacks1 opened this issue Mar 28, 2023 · 2 comments
Open

"next-version" as a Commit Message Action #33

nickajacks1 opened this issue Mar 28, 2023 · 2 comments

Comments

@nickajacks1
Copy link
Contributor

The implementation for next-version is currently hard coded, but it would be nice to be able to gain the flexibility provided by the configuration.
Using GitFlow as an example, one may wish to automatically set the version based on the merge of a branch to master.

commit 8b0d111883980b033aaae7158552712ebf15746f (origin/main, main)
Merge: 476e967 8775451
Author: Susan Programmer <[email protected]>
Date:   Mon Oct 17 23:38:49 2022 +0000

    Merged in release/v1.4.5 (pull request #7)

A potential configuration to allow automatically setting the version:

commitMessageActions: [
  {
    pattern: "Merged in release/v(\\d+\\.\\d+\\.\\d+)"
    action: SetVersion
  }
]

It would be possible to use a regex capture to extract the version from the commit.

@idc101
Copy link
Owner

idc101 commented Sep 15, 2023

I'll look at this. What do you think should be the behaviour if SetVersion says 1.5.0 but the semantic versioning has a calculated 2.0.0 because of a breaking change?

@nickajacks1
Copy link
Contributor Author

I think if the developer went out of their way to set the specific version, we probably would want to let that take precedence.
By setting the version, you're really saying "I want to forfeit the automatic versioning and use this version."
So IMO if there is at least one SetVersion action in the commit history, we should take the latest one as the exact version to use for next.
I'm not sure how others would use this feature, but perhaps if there are worries about leaking a truly breaking change then a (suppressable?) warning could be printed if a breaking change is detected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants