-
Notifications
You must be signed in to change notification settings - Fork 25
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
Bump version to 2.5.0 and document release process. #256
Conversation
Good news: this fixed the https://github.com/iree-org/iree-turbine/actions/workflows/test_build_release.yml workflow that has been stalling. I'd like to investigate why it fixed it, but I might just settle for it working for now... |
Tested locally. The instructions in the doc are accurate. The only hiccup I see is that |
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.
Looks good to me but I am not able to an in depth review before tomorrow. But feel free to merge as the CI passes 🥳
# Compute package-version. | ||
package_version = eval_version(args.package_version) | ||
if args.package_pre_version: | ||
package_version += eval_version(args.package_pre_version) | ||
if args.package_post_version: | ||
package_version += f".{eval_version(args.package_post_version)}" | ||
info_dict["package-version"] = package_version |
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.
Yet another way to compute / parse the version numbers. I assume we want to harmonize this over the projects when switching iree-turbine to the new versioning scheme? Nothing for this PR, just considerations.
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.
Probably, yeah. I'm not sure how I feel about the explicit version specification in commands like ./build_tools/build_release.py --package-version 2.5.0 --package-pre-version=rcYYYYMMDD
is. In the other projects we pull that from the version file.
After merging this, I plan on running the build script locally and pushing 2.5.0 to PyPI and a GitHub release. We could also have |
Ah, it was moved to https://github.com/iree-org/iree/blob/main/RELEASING.md#build-promotion. I'd like to merge that file with https://iree.dev/developers/general/release-management/ to have a single place to look. |
The
docs/releasing.md
file was first introduced next to thebuild_release.py
script in nod-ai/SHARK-ModelDev#605. I don't see that file in this repository (iree-org/iree-turbine) though, despite nod-ai/SHARK-ModelDev#655 claiming that it had been upstreamed. Since the packages involved have changed over the months (shark-turbine --> iree-turbine naming, see also #28), I also updated the document to reflect the current setup.The
iree-requirements.txt
file was being used to pin versions of theiree-compiler
andiree-runtime
that would be released together with thisiree-turbine
package. That was overlooked when #115 removed pins from that file. I've reworked the script to referenceiree-requirements-ci.txt
for now, but we can continue to iterate on the cross-project release process going forward (with docs this time).I've updated the version in code from 2.3.0 to 2.5.0. We can push a release to https://github.com/iree-org/iree-turbine/releases and https://pypi.org/project/iree-turbine/#history using the new version next. Note that 2.3.1, 2.4.0, and 2.4.1 were released to PyPI without updating the code or GitHub releases.