release: bump to 1.5.0b1, the wave-1 beta - #488
Merged
Merged
Conversation
Wave 1 is closed -- twelve PRs merged and ten issues closed (#465, #472, #467, #445, #473, #476, #469, #477, #483, #443) -- so the two-step release plan in docs/source/pep.rst calls for a beta here, with the official 1.5.0 after the post-wave-1 consistency sweep. Version string only, and deliberately its own commit, because it IS the release trigger and should never be buried in an unrelated change. create-release.yml is version-driven rather than tag-driven, reached from an ordinary push: a push to main runs Vendor Update, whose completion runs Create Release, which reads pcapkit.__version__ and publishes only when the tag v<version> does not yet exist. That gate is why nothing published today despite Create Release running on every push -- v1.5.0a1 is already tagged. v1.5.0b1 is not, so this commit publishes. Measured for this version: is_prerelease=True, so the GitHub release is marked prerelease and the Anaconda label stays dev; PyPI gets it but only `pip install --pre` resolves it. The consequential flip to a full release and the main conda label comes at 1.5.0, not here. #487 remains open and is deliberately not a wave-1 blocker.
The sibling commit moves pcapkit.__version__ to 1.5.0b1, which made two statements in the release plan stale: the prose asserting the version "is already 1.5.0a1", and the table row labelling 1.5.0a1 as current. Step 1 is now marked done, with the two things the sweep has already turned up named rather than left abstract. Also records how create-release.yml is actually reached, which reading its `on:` block alone gets wrong -- it lists only a v* tag push and a workflow_run, which reads as "an ordinary commit cannot trigger this". The real chain is that a push to main runs Vendor Update, whose completion runs Create Release, and every publishing job is gated on the tag for the current version not already existing. That gate is why ordinary commits do not publish even though the workflow runs on all of them, and why changing the version string is what arms it. I had this wrong out loud today -- read the trigger list, concluded the version string was not the release button after all, and had to retract that after checking the run history. Writing the chain down so the next reader does not repeat it. Docs only.
JarryShaw
added
ci
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.
Bumps
pcapkit.__version__from1.5.0a1to1.5.0b1, per the two-step release plan recorded indocs/source/pep.rst: a beta once wave 1's issues are closed, the official1.5.0after the post-wave-1 consistency sweep.Wave 1 is closed. Twelve PRs merged, ten issues closed:
mainis at36231cab4with zero open PRs. One issue remains open — #487, theIPv6_RouteSource-Route round-trip defect — which is deliberately not a wave-1 blocker and does not gate this beta.Merging this publishes. Here is exactly what happens.
This is the whole of the release mechanism, so it is worth being precise rather than leaving it to be rediscovered.
.github/workflows/create-release.ymlis version-driven, not tag-driven, and it is reached by a chain from an ordinary push:Create Release'sversion_checkjob readspcapkit.__version__directly, derivesPCAPKIT_PRERELEASEfrompackaging.version.Version(...).is_prerelease, picks the Anaconda label from the same test, and checks whether the tagv<version>already exists. Every publishing job —github,tag,pypi,conda— is gated onstartsWith(github.ref_name, 'v') || PCAPKIT_TAG_EXISTS == 'false'.That gate is why nothing has been published today despite
Create Releasehaving run on every single push tomain:v1.5.0a1is already tagged, soPCAPKIT_TAG_EXISTSistrueand all four jobs skip. Verified against the actual run history rather than inferred from the YAML.So merging this one-line change arms and fires the release, because
v1.5.0b1does not exist. Measured for this exact version string:Version('1.5.0b1').is_prereleaseTruedevv1.5.0b1pip install --preThe consequential flip to a full release and the
mainAnaconda label comes later, at1.5.0, not here.Why a beta rather than going straight to
1.5.0The post-wave-1 consistency sweep has not run, and its entire purpose is to find what one-at-a-time defect work does not — prose against code, missing tests, unaligned changes, and packet formats against their specifications. Shipping a final release before it has run would be shipping ahead of the evidence.
Today already produced two demonstrations of that: #485's ipv6-route test exists because #480's fix shipped with no test of its own, and #487 was found only because someone went looking sideways while writing that test.
Verification
Version string only — one line, no logic:
Confirmed the package reports it, with
pcapkit.__file__asserted against this tree before import:It is deliberately its own commit, touching nothing else, so that the release trigger is never buried inside an unrelated change.