-
Notifications
You must be signed in to change notification settings - Fork 612
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Apply new versioning scheme #19034
Apply new versioning scheme #19034
Conversation
This implements a new versioning scheme, similar to the one recently proposed with iree-org#18938 and applies it to `iree-compiler`, `iree-runtime` and the `iree-dist` tarball. The TF and TFLite compiler tools use the (legacy) versioning and need to be updated with a follow up commit. The common version number is determined based on the versions of the compiler and the runtime and the higher version is picked as the common on. In contrast to the proposed versioning scheme, version numbers of development releases are in the format `X.Y.Z.dev0+${gitcommithash}` as discussed in iree-org#19003 and not `X.Y.Z.dev` as originally proposed. Not yet addressed is the refactoring of the workflows thus that the `version-local.json` files get only written once (and not for every OS) and to provide then to subsequent steps as artifacts.
I tested builds locally (development releases) and triggered the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The overall structure of this LGTM. Some comments on the mechanics and style.
35f942a
to
3f41929
Compare
.github/workflows/build_package.yml
Outdated
jobs: | ||
# Note: metadata generation could happen in a separate trigger/schedule | ||
# workflow. For cross platform builds, it's useful to just generate the | ||
# metadata on Linux and pass that to later jobs using artifacts. | ||
setup_metadata: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think I meant for this to go in a workflow like schedule_candidate_release.yml
as I was writing this comment for https://github.com/nod-ai/SHARK-Platform. This repository already has that workflow, and it could produce this metadata alongside the other workflow inputs (package_version
, compiler_package_version
, etc.). Fine to keep this here as a job in build_package.yml
, but may want to clarify the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was considering this as well and it is the logical next step. I iterate on it if I find some time for it tomorrow. Sending a patch to update the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the comment accordingly. Depending on when you want to merge this, I can also fill an issue to address moving this to in a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could merge it soon, though we may want to also update the package names to iree-base-compiler
and iree-base-runtime
alongside the new versions. If we just land this as-is, users won't automatically get the new versions from nightly or stable releases from pip
.
Maybe having this PR just roll out the versions and then a follow-up change the names is fine.
This documents the versioning scheme proposed with iree-org#18938, refined as part of the discussion iree-org#19003 (first drafted patch) and iree-org#19034 (second drafted patch) and applied with commit 6d55a11.
This documents the versioning scheme proposed with iree-org#18938, refined as part of the discussion iree-org#19003 (first drafted patch) and iree-org#19034 (second drafted patch) and applied with commit 6d55a11.
This implements a new versioning scheme, similar to the one recently proposed with #18938 and applies it to
iree-compiler
,iree-runtime
and theiree-dist
tarball. The TF and TFLite compiler tools use the (legacy) versioning and need to be updated with a follow up commit. The common version number is determined based on the versions of the compiler and the runtime and the higher version is picked as the common on. In contrast to the proposed versioning scheme, version numbers of development releases are in the formatX.Y.Z.dev+${gitcommithash}
as discussed in #19003 and notX.Y.Z.dev
as originally proposed.