Fix: bump minor, not patch, for features #1111
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
From the wonderful world of "we have opinions but we don't document them" comes "we provide a sane default configuration but we don't document it." When 5c21ba3 introduced a configuration file for release please, it replaced a built-in default configuration, which does not consist of the default values but a particular set of hand-picked values, with one where default values suddenly apply. In other words, by having an explicit configuration, all the options for which a value is not supplied use the default value. By *not* having a configuration, a predefined one is used, which is not composed of all the default values for all the options. I do not have the time to figure out where this default configuration comes from, but I can see that it does one thing if an empty configuration is provided and a different thing if no configuration is provided. At first glance, it seems to be the CLI flags but I do not know. Part of that sane default configuration is that when a feature is added, the minor version should be bumped, even if there hasn't been a major release yet. The default value, bump patch unless there's has been a major release already, is indeed a surprising bad default. Signed-off-by: Marcelo E. Magallon <[email protected]>
ka3de
reviewed
Dec 16, 2024
| @@ -3,6 +3,7 @@ | |||
| ".": { | |||
| "release-type": "go", | |||
| "bump-minor-pre-major": true, | |||
| "bump-patch-for-minor-pre-major": false, | |||
There was a problem hiding this comment.
I reviewed this and, at least based on documentation, this should default to false anyway, but we can set it explicitly just in case. You can see the full config spec here: https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md#configfile.
I still don't understand the issue we see in #1094, as the same "behavior" worked correctly in the past with the same configuration. See #954.
ka3de
approved these changes
Dec 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From the wonderful world of "we have opinions but we don't document them" comes "we provide a sane default configuration but we don't document it."
When 5c21ba3 introduced a configuration file for release please, it replaced a built-in default configuration, which does not consist of the default values but a particular set of hand-picked values, with one where default values suddenly apply. In other words, by having an explicit configuration, all the options for which a value is not supplied use the default value. By not having a configuration, a predefined one is used, which is not composed of all the default values for all the options.
I do not have the time to figure out where this default configuration comes from, but I can see that it does one thing if an empty configuration is provided and a different thing if no configuration is provided. At first glance, it seems to be the CLI flags but I do not know.
Part of that sane default configuration is that when a feature is added, the minor version should be bumped, even if there hasn't been a major release yet. The default value, bump patch unless there's has been a major release already, is indeed a surprising bad default.