Simplify version management and update for next release#267
Merged
dbutenhof merged 5 commits intocloud-bulldozer:mainfrom Aug 21, 2025
Merged
Simplify version management and update for next release#267dbutenhof merged 5 commits intocloud-bulldozer:mainfrom
dbutenhof merged 5 commits intocloud-bulldozer:mainfrom
Conversation
As a general principle, it makes sense to update the internal version number as soon as we've completed a release so that dashboard-dev is clearly distinguished from dashboard. So having released v0.2.1, I'm updating the version to v0.2.2. When I created the version.py build script, I'd envisioned reading the version directly from the pyproject.toml file, but for "simplicity" (of implementation) I ended up creating a separate VERSION file with the base version string. While easy to write, this is harder to manage over time. Python 3.11 includes a built-in tomllib package, but as we're still depending on 3.9 I experimented with several alternatives -- toml can't parse our pyproject.toml and was difficult to debug; but tomlkit is recommended by Python documentation (for pre-3.11 and for writing toml files), and that works. So we now have [project] version = "v0.2.2" as our only source of version truth in the repo, and the version.py script is now able to read that and generate our live version information from that.
Apparently, `version.py` was (successfully) relying on having all dependencies installed in the current context, whereas they might not be (and `tomlkit` is not). So run `version.py` inside a `poetry run` command.
I'm now relying on `poetry` earlier in order to generate the version information outside the target container, and this affects all of the GitHub Action environments that build the backend. These are harder to test, too, so we'll see ...
MVarshini
approved these changes
Aug 21, 2025
Collaborator
Author
|
Had some problem setting up the GitHub runner for |
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.
Type of change
Description
As a general principle, it makes sense to update the internal version number as soon as we've completed a release so that
dashboard-devis clearly distinguished fromdashboard. So having released v0.2.1, I'm updating the version to v0.2.2.When I created the
version.pybuild script, I'd envisioned reading the version directly from thepyproject.tomlfile, but for "simplicity" (of implementation) I ended up creating a separateVERSIONfile with the base version string. While easy to write, this is harder to manage over time.Python 3.11 includes a built-in
tomllibpackage, but as we're still depending on 3.9 I experimented with several alternatives --tomlcan't parse ourpyproject.tomland was difficult to debug; buttomlkitis recommended by Python documentation (for pre-3.11 and for writing toml files), and that works.So we now have
[project] version = "v0.2.2"as our only source of version truth in the repo, and theversion.pyscript is now able to read that and generate our live version information from that.Related Tickets & Documents
PANDA-1014 version update
Checklist before requesting a review
Testing
Local unit tests, frontend & backend functional tests, plus
black,isortandflake8checks.