Add in-development version support #4865
Conversation
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
NoDocumentationNeeded
NoReleaseNotesNeeded
devinrsmith
requested review from
chipkent,
jmao-denver,
rcaudy,
jcferretti and
stanbrub
as code owners
|
The properties, extra suffix, and default of using SNAPSHOT should be suitable for Enterprise and eliminate the confusion we have now about whether "0.31.0" is really the released version. |
There was a problem hiding this comment.
It is not clear to me from the description or the code what are the changes to the release process in terms of tagging before/after release; as of before this PR, the procedure is to edit sources that mention versions (the list of files to edit is given in RELEASE.md) and put in them the version number that will be released "next" (eg, if we just released 0.29.0, the files are edited right after release to point to 0.30.0). This means that when the release comes the version to be released is already in those files, so before a release there is no need to change any versions in any files.
Since there are no changes in RELEASE.md mentioning any of that in this PR, it would seem that nothing has changed about that on this PR. But I don't understand how can that be the case given the description.
There are no changes to the release part of the process - the publish workflow removes the "-SNAPSHOT" suffix automatically. After release, the manual editing of version numbers has been greatly simplified (from ~10 files -> 2 files). |
| # Edit files for version change | ||
| # | ||
| authorization-codegen/protoc-gen-contextual-auth-wiring | ||
| authorization-codegen/protoc-gen-service-auth-wiring | ||
| buildSrc/src/main/groovy/io.deephaven.common-conventions.gradle | ||
| py/client-ticking/README.md | ||
| py/client-ticking/setup.py | ||
| py/client/README.md | ||
| py/client/pydeephaven/__init__.py | ||
| py/client/setup.py | ||
| py/embedded-server/deephaven_server/__init__.py | ||
| py/server/deephaven/__init__.py | ||
| gradle.properties |
There was a problem hiding this comment.
Glorious. Also kind of neat how the example version bump above is 0.31.0 to 0.32.0 and was written a few months ago, which is assumedly going to actually be our next bump after this merges.
devinrsmith
dismissed stale reviews from jcferretti, jmao-denver, and stanbrub
via
f4e3417
Agreed. I think #2233 would allow this to be more easily solved - much easier to specify build related dependencies then. |
devinrsmith
requested review from
mofojed,
stanbrub,
jmao-denver and
jcferretti
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