ci(nightly): anchor nightly version to upcoming release in pyproject.toml#645
Merged
Merged
Conversation
…toml
Previously the nightly publish workflow hard-coded the base version as
0.0.0, producing wheels like 0.0.0.dev20260427+pt280.cu128. This made
nightlies sort below every real release and gave no hint of which
release cycle they belonged to.
Read the current `version` from pyproject.toml instead, strip any
trailing pre/dev/post segment and local label, and use the resulting
base release as the anchor. With pyproject.toml at 0.5.0.dev0 today's
nightly becomes 0.5.0.dev20260427+pt280.cu128, which under PEP 440
sorts as:
0.5.0.dev0 < 0.5.0.devYYYYMMDD+ptX.cuY < 0.5.0
so `pip install --pre fvdb-core` tracks nightlies until 0.5.0 ships,
prefers the final release once tagged, and resumes tracking nightlies
after the next dev-cycle bump. Fails fast if the version string can't
be parsed.
Signed-off-by: Jonathan Swartz <jonathan@jswartz.info>
swahtz
added
CI
Contributor
Author
|
@phapalova I was thinking of making the change to make our nightly build versions make more sense. This would make depending on dev/yet-to-be-released version numbers easier for downstream users… you wouldn't have the confusion of needing '0.0.0'(nightly number) OR '0.5.0' (unreleased dev version). Is that an improvement for your needs? |
Contributor
Thanks that will simplify the way we pull the nightly |
phapalova
approved these changes
Apr 27, 2026
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
2 participants
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.
Previously the nightly publish workflow hard-coded the base version as 0.0.0, producing wheels like 0.0.0.dev20260427+pt280.cu128. This made nightlies sort below every real release and gave no hint of which release cycle they belonged to.
Read the current
versionfrom pyproject.toml instead, strip any trailing pre/dev/post segment and local label, and use the resulting base release as the anchor. With pyproject.toml at 0.5.0.dev0 today's nightly becomes 0.5.0.dev20260427+pt280.cu128, which under PEP 440 sorts as:so
pip install --pre fvdb-coretracks nightlies until 0.5.0 ships, prefers the final release once tagged, and resumes tracking nightlies after the next dev-cycle bump. Fails fast if the version string can't be parsed.