chore: drop the release config the workflow never reads - #49
Merged
Conversation
`release-please-config.json` declared `bump-patch-for-minor-pre-major: true`, which would make a feature a patch bump on a pre-1.0 package. The release workflow passes only `release-type: node` and no `config-file`, so release-please runs inline and never reads the file. The setting has therefore never applied: v0.8.2 to v0.9.0 was a single `feat:` and produced a minor bump, not the v0.8.3 the file asks for, and the same is true of every earlier feature release. Nothing references the file, and `.release-please-manifest.json` is unaffected: that one is genuinely live and is rewritten by every release commit. Removing the config changes no behavior; it removes a file that documented a policy the project has never followed and that a future maintainer would reasonably trust. Wiring it in instead would have been the other way to resolve this, but that switches release-please to manifest mode and would change how the next version is derived. That is a policy decision rather than a cleanup, so it is left alone.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
release-please-config.jsondeclaredbump-patch-for-minor-pre-major: true, which on a pre-1.0 package makes a feature a patch bump. The release workflow passes onlyrelease-type: nodeand noconfig-file, so release-please runs inline and never reads the file.The setting has therefore never applied. The clearest proof is in the history:
feat:feat:feat:Every feature release took the minor bump the file forbids.
Why remove rather than wire it in
Nothing references the file, and
.release-please-manifest.jsonis unaffected: that one is genuinely live and is rewritten by every release commit, including v0.10.0.Adding
config-file:to the workflow was the other way to resolve the contradiction, but it switches release-please into manifest mode, which changes how the next version is derived, and it would make future features patch bumps instead of minor. That is a policy change, not a cleanup, so it is deliberately left alone. If the patch-bump policy is actually wanted, it should be a separate deliberate PR.Removing the file changes no behavior. It removes a file that documented a policy the project has never followed and that a future maintainer would reasonably trust.
Verification
Build, lint, 431 tests and the committed-
distcheck all pass. The next release will behave exactly as v0.10.0 did.