chore: drop the unused Create Release workflow and correct the release baseline - #84
Merged
Merged
Conversation
…e baseline The Create Release workflow was added three weeks before release-please and has never run once. It could not have: it writes to custom_components/open_display/manifest.json, an underscored path that does not exist, so its bump step fails immediately. Two further faults had it ever been used — its version regex allows no dot in the prerelease part, rejecting the beta.N form every pre-release uses, and it calls `gh release create` without --prerelease, which would publish a beta as stable and push it to every HACS user rather than only those opted in to betas. Releases on main are cut by release-please, and pre-releases are cut by hand from the dev branch. Neither uses this workflow, so it is removed rather than repaired. Also corrects the release-please baseline. It recorded 2.0.2, the last version release-please itself released, while the project has since published 3.0.0-beta.9 through the manual pre-release path that release-please never sees. Left stale, the first release after the dev branch merges anchors to 2.0.2 and can propose a version below what users already have. Tags are untouched: release-please's own releases are bare per include-v-in-tag, and the hand-cut betas keep their v prefix. The two series are each internally consistent.
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
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.
Two small changes, both about how releases actually get cut here.
Remove
.github/workflows/release.ymlIt was added three weeks before release-please and has never run — not once. It could not have: it writes to
custom_components/open_display/manifest.json, an underscored path that does not exist, so the bump step fails immediately.Two further faults, had it ever been used:
(-[a-zA-Z0-9]+)?$allows no dot in the prerelease part, so it rejects3.0.0-beta.9— the form every pre-release here usesgh release createis called without--prerelease, so a beta would publish as stable and HACS would offer it to every user, not only those opted in to betasReleases on
maincome from release-please; pre-releases are cut by hand from the dev branch. Nothing uses this workflow, so it is removed rather than repaired.Correct the release-please baseline
.release-please-manifest.jsonrecorded2.0.2— accurate as the last version release-please itself released, but the project has since published up to3.0.0-beta.9through the manual pre-release path, which release-please never sees.Left stale, the first release after this branch merges to
mainanchors at2.0.2and proposes a bump from there — potentially a version below what users already have. Set to3.0.0-beta.9so the next release starts from reality.For the 3.0.0 stable cut, a
Release-As: 3.0.0footer on a commit tomainremoves any ambiguity about graduating from the beta series.Tags are deliberately left alone
The two tag styles are not a mistake. release-please's own releases (
2.0.0,2.0.1,2.0.2) are bare becauseinclude-v-in-tagisfalse; the hand-cut betas (v3.0.0-beta.1…v3.0.0-beta.9) carry thev. Each series is internally consistent, so no config change here.uv run pytest— 94 passed.