Simplify version bump #3466
Comments
devinrsmith
added a commit
to devinrsmith/deephaven-core
that referenced
this issue
Nov 20, 2023
This adds support for in-development versioning of jars and wheels. Specifically, this PR translates the java version qualifier (anything after "-") to a python "local version label" (`<public version identifier>[+<local version label>]`). For example, the java version "1.2.3-SNAPSHOT" becomes python version "1.2.3+SNAPSHOT"; the java version "4.5.6-my-custom-build123" becomes python version "4.5.6+my.custom.build123". By using a "local version identifier", these wheels become development-only artifacts - they can't be publicly published. While we could contemplate using "development release segments" (ie, python versios that look like "X.Y.Z.devN"), we wouldn't be able to generally translate java versions to python versions without enforcing more structure onto our java versions. As an added benefit, this PR also reduces some of the duplication of version numbers by sourcing the version number as appropriate during the wheel building process; and then also in the runtime python code, sourcing the version information via the appropriate importlib metadata APIs. See https://packaging.python.org/en/latest/specifications/version-specifiers/# See https://peps.python.org/pep-0440/ Partial deephaven#3466 Fixes deephaven#4654
devinrsmith
added a commit
that referenced
this issue
Nov 24, 2023
This adds support for in-development versioning of jars and wheels. Specifically, this PR translates the java version qualifier (anything after "-") to a python "local version label" (<public version identifier>[+<local version label>]). For example, the java version "1.2.3-SNAPSHOT" becomes python version "1.2.3+snapshot"; the java version "4.5.6-my-custom-build123" becomes python version "4.5.6+my.custom.build123". By using a "local version identifier", these wheels become non-public artifacts - they can't be publicly published. While we could contemplate using "development release segments" (ie, python versios that look like "X.Y.Z.devN"), we wouldn't be able to generally translate java versions to python versions without enforcing more structure onto our java versions. As an added benefit, this PR also reduces some of the duplication of version numbers by sourcing the version number as appropriate during the wheel building process; and then also in the runtime python code, sourcing the version information via the appropriate importlib metadata APIs. This also improves our versioning support (now supported via property changes instead of hard-coded buildSrc changes), and gives re-builders options when defining their own version. See https://packaging.python.org/en/latest/specifications/version-specifiers/# See https://peps.python.org/pep-0440/ Partial #3466 Fixes #4654
|
One tool that might be handy is Cocogitto. Using that tool in combination with conventional commits (as enforced with #5528) you could automatically bump the version/build release notes. Also, I would consider doing a branch named |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, there are a variety of files where the deephaven-core version are specified. After the release process, it's a manual find and replace to update the relevant versions. It would be much improved if we could specify the version once and either have automation update other version numbers as appropriate, or have that single version as the source-of-truth.
The current list of files is listed in RELEASE.md at the toplever directory of deephaven-core, in step 2.
The text was updated successfully, but these errors were encountered: