Option to increment minor or major version instead of patch #212
Comments
|
hey, need help on that? |
|
Hey @enzian, sure thing! I guess, from the user's perspective, this would result in a new property. Something like: <MinVerAutoIncrement>major|minor|patch(default)</MinVerAutoIncrement>I'm not wild about the name |
|
I preliminarily introduced the |
|
@enzian thanks for the PR! But also apologies, because I was not clear in my previous comment: <MinVerAutoIncrement>major|minor|patch(default)</MinVerAutoIncrement>I was using <MinVerAutoIncrement>patch</MinVerAutoIncrement>And that could be changed to: <MinVerAutoIncrement>minor</MinVerAutoIncrement>or: <MinVerAutoIncrement>major</MinVerAutoIncrement>I can't think of a valid use case to auto-increment more than one part of the version. |
|
@adamralph : I've seen (just once...) that a company did not release versions like 2.0.0. The first version they would release was 2.1.0 (for what reason is unclear to me...)! Should I switch to a single value? |
|
That sounds like a bizarre versioning scheme and not one I really want to encourage. 😉 I think, for now, let's stick to a single value for simplicity. We can always extend it to multiple values later, but I hope noone asks for that. 😉 |
|
@adamralph maybe it was also a case of over engineering is underrated ;-) I patched it! |
adamralph
changed the title
The when applying minver, a user should be able to override the default behavior of how versions are incremented. The current behavior is, that whenever minver is run on a commit, that does not carry a minver tag and is at a height > 0 from the last minver tag, the patch version will be incremented and the height added. For example: When the latest tag is 1.2.3 and the commit is at a height of 1 from this tag, the resolved version will be 1.2.4-alpha.0.1. This behavior should be customizable by setting a property that defines what segments of the version (major, minor, patch) should be incremented. addresses: #212
For msbuild, the -i parametere has been switched to single-value parameter that accepts a comma separated list of version segments to increment. The msbuild target was extended to support the new MinVerAutoIncrement property. It's default value is set to `patch` but can be set to `major`, `major, minor` or `major, minor, patch`. Order is not relevant. It also possible to increment combinations like `major, patch` or `minor, patch`. addresses: #212
There is new documentation on the various combinations of autoincrementation of versions. These samples should correspond to the testcases and be validated. addresses: #212
Until now it was possible to increment multiple segments of a version when autoincrementation happened. This behavior is not backed by a sensible use case has been removed. addresses: #212
|
Released in 1.1.0-beta.1. @leastprivilege would you like to give it a try? Just add a property: <MinVerAutoIncrement>minor</MinVerAutoIncrement> |
|
sorry - swamped right now... |
|
@leastprivilege FYI I just pushed 1.1.0-rc.1. |
When the latest tag is an RTM, and is on an older commit, the patch version is incremented. E.g. if the latest tag is
1.0.0at a height of 3 commits, the current commit version is1.0.1-alpha.0.3.Some projects do not use the patch version, so it would make more sense for the version to be
1.1.0-alpha.0.3. Some projects may even not use the minor version, which means the version should be2.0.0-alpha.0.3.This could be configurable via a new option.
The text was updated successfully, but these errors were encountered: