You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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?
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.
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.
A potential configuration to allow automatically setting the version:
It would be possible to use a regex capture to extract the version from the commit.
The text was updated successfully, but these errors were encountered: