1.0.0 - Semantic releases! #252
in03
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Huzzah! Automated semantic-releases are here!
This release marks the beginning of an automated semantic release cycle using python-semantic-release. It's been a year and a half since Proxima started on GitHub (back on the 28th of April 2021). Before then it was a two-year working collection of scripts that read .txt files for encoding jobs.
The old way
Until now, managing queuer/worker compatibility was maintained using a version-constraint key (a simple animal codename like 'quizzically-queer-quail') generated by CI/CD on each git push. This allowed for guaranteed queuer/worker compatibility across installation methods: pip/pipx, git/vcs, local repo clone, release install, etc. The plan was always to use semantic versioning as the version-constraint system eventually, but there were so many breaking changes in early dev that we'd but up to version 49.0.0 by now.
Why the change now?
While generating version-constraint-keys on repo push worked great to prevent incompatible workers from taking jobs, it was a big hindrance to development. Even the smallest bug-fix would require complete re-installation on each test-machine in the cluster. The code to get build info was also overly complicated and hacky for diminishing-returns: it needed to check if the installation was a local git-repo, installed via pip/pipx with a git URL or if it was a release install, and pass or fail instances in the cluster accordingly... Just a bit too much user hand-holding in the end.
What does that look like now?
For now, the version-constraint-key uses the package's
__version__
which also matchespypackage.toml
. Python-semantic-release handles bumping the hardcoded version variables based on conventional-commits (fix:
,feat:
,BREAKING CHANGE
, etc). For the time being, the version-constraint uses both themajor
andminor
semver numbers. This means that aminor
change will create incompatibilities. Until there is solid compatibility testing to check for breaking changes, this is safer. This removes all the complexity of maintaining the complicatedBuildInfo
class, whilst also preventingpatch
level changes from creating incompatibilities. This release version will be incompatible with all prior git versions.What's Changed?
This is actually everything since Proxima started, since we've never done a release! (This list doesn't include every change I pushed straight to 'main' which I'm ashamed to say was a lot)
New Contributors
Full Changelog: https://github.com/in03/proxima/commits/0.1.0
This discussion was created from the release 1.0.0 - Semantic releases!.
Beta Was this translation helpful? Give feedback.
All reactions