You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 matches pypackage.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 the major and minor semver numbers. This means that a minor 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 complicated BuildInfo class, whilst also preventing patch 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)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
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