Release 1.9.0 Checklist

[MarcelKoch]

Pre Release / Prerequisites

• Create release project and milestone
• Manage open bugs
• Check CUDA/HIP/SYCL versions
  • Remove code for unsupported versions

Step-by-Step

• Update develop branch
  • Update TPLs
    • gflags
    • googletest ([release] update gtest #1740)
    • nlohmann_json
  • Update Changelog using the unreleased changes from the wiki ([release] update changelog #1741)
  • Change version tag in CMakeLists.txt to main (PR-tag)
• Manually check building with newest compiler versions
  • see the CI for the branch check-latest
• Manually check packaging CI (until automated)
  • see the CI for the branch spack-ci
• Manually check threadsanitizer CI (until automated again)
• Merge develop into main, with merge commit (i.e. --no--ff)
• Create github release with new tag vX.Y.Z on main

Post Release

• Announce the release:
  • LinkedIn
  • E-Mail lists: NADigest
• Add new version to package managers
  • spack: https://github.com/ginkgo-project/spack
  • vcpkg
  • conan
• Publish release on zenodo
• Prepare develop for next release (Prepare Develop for 1.10 Release #1747 )
  • Revert PR-tag on develop
  • Update version on develop to X.Y+1.0
• In addition, until 2026:
  • Create branch master-release/X.Y.Z from main
  • Change version tag to master
  • Squash merge into master (Master release/1.9.0 #1748)

[MarcelKoch]

This issue is also meant to become a new template which we will use for following releases.

[MarcelKoch]

This release approach contains some changes to the previous releases, especially how master is handled.

I think in earlier releases all commits after the last release where cherry-picked onto master with an additional merge commit. Although I'm not entirely sure about that. The point is however that the develop branch was not merged into master.

I think this should change, and the release PR should just be a normal merge from develop into master. This is not really possible, since master and develop don't have a common history (or at least after the 1.0 release). Thus I'm introducing the main branch which will have the future releases. This branch will have a shared history with develop in the form of the release merge commits. Here is a diagram how I think the main, and develop branch should be connected (feature stands for our normal development workflow, but that can be realized without a bunch of extra branches):

gitGraph TB:
	commit
	branch develop
	checkout develop
	commit
	branch feature
	checkout feature
	commit
	commit
	checkout develop
	merge feature
	checkout feature
	commit
	commit
	checkout develop
	merge feature
	checkout main
	merge develop tag: "vX.Y.Z"
	checkout feature
	commit
	commit
	checkout develop
	merge feature
	checkout feature
	commit
	commit
	checkout develop
	merge feature
	checkout main
	merge develop tag: "vX'.Y'.Z'"

Loading

[upsj]

We should also add Conan to the package managers, even though we don't really do much work there.

On the release workflow, I want to propose a slight change:

If we introduce the "Change version tag in CMakeLists.txt to main" change into develop as well, we can separate this into a PR (PR1) on develop that changes the tag (few lines) and a PR (PR2) on main that is purely fast-forwarding main onto develop, and then a PR (PR3) that reverts the first PR on develop. That means that PR1 and PR3 are easy to review, and PR2 doesn't include any new changes, so it doesn't need any actual reviews.

[MarcelKoch]

I guess the question is if we want to have an extra merge commit on main to denote the release. I think we can use your approach either way, and I would also prefer it.

[yhmtsai]

are the vcpkg and conan contributed by us?
the update version in post release should be X.Y.Z -> X.(Y+1).0 for minor update

[yhmtsai]

For merging to master, I assume you will not change the version tag as master from the beginning.
should we just squash all commit to the master?

[MarcelKoch]

For master, I initially thought I would just cherry pick all commits from develop into master. But squashing all the commits might be the better choice. I don't really care how the history of master will look like in the future, I just want to have the latest changes in it.
I will also leave the tags as they already are.

[MarcelKoch]

BTW you can see how the history of the main branch should look like at: https://github.com/MarcelKoch/ginkgo/tree/main-with-merges. This example has two merges from develop into the main branch to "simulate" our release process.
@upsj I would actually prefer to have explicit merge commits instead of fast-forwarding. I don't think you can FF merge through the github PR interface anyway. The explicit merge commits also have the effect that using the --first-parent option when looking at the history, will directly give you the release commits.

[yhmtsai]

It will also be great if you can link the step to the pr such that we might be able to see more detail on that.
Some of them sometimes are not obvious like link name from develop to main in ReadME.md