Skip to content
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

Update release procedure #1250

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Update release procedure #1250

wants to merge 10 commits into from

Conversation

RMeli
Copy link
Member

@RMeli RMeli commented Dec 19, 2024

The CHANGELOG in master does not contain release notes for 0.7.1. Add this step to the RELEASE_PROCEDURE.

Improve release procedure, especially for patch releases. (Lessons learned...)

Copy link
Collaborator

@msimberg msimberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the 0.7.2 release, let's add at least the following

  • always add release notes to the master branch even for patch releases to avoid mismatch between release and master branch
  • always cherry pick changes from master to release branch (changes and release notes)
  • can we add something about checking the release branch to make sure it matches what's in the release notes? (at the very least a manual inspection check to compare the release branch to the previous release?)

@rasolca
Copy link
Collaborator

rasolca commented Dec 19, 2024

I would add to not release until tests passed. I.e. wait that the tests complete for master (major release) or the version branch (minor and patch).

RELEASE_PROCEDURE.md Outdated Show resolved Hide resolved
RELEASE_PROCEDURE.md Outdated Show resolved Hide resolved
RELEASE_PROCEDURE.md Show resolved Hide resolved
RELEASE_PROCEDURE.md Outdated Show resolved Hide resolved
RELEASE_PROCEDURE.md Outdated Show resolved Hide resolved
@RMeli
Copy link
Member Author

RMeli commented Dec 20, 2024

For patch releases maybe we should add a step to also add branch protection rules? Currently only version_0.3 is protected (version_0.4 is not).

@msimberg
Copy link
Collaborator

Should we mention something about using GitHub's milestones for a release? Currently they're not mentioned, but we sort of use them. I created one for 0.7.3 now: https://github.com/eth-cscs/DLA-Future/milestone/31.

@msimberg
Copy link
Collaborator

Idea from @RMeli: check automatically that the release branch has non-trivial commits since the previous version tag. Perhaps checking for changes to cpp and other source files in the src directory? May need overriding if making a patch release which only changes/fixes e.g. cmake files. Updating the version in CMakeLists.txt would already satisfy this check which is not what we want?

Then again, we should not go completely overboard with checks either...

@RMeli
Copy link
Member Author

RMeli commented Dec 20, 2024

I think I didn't explain myself well, but what I meant was to add a check to the release script to ensure that the tests (CI) have passed, if this is at all queryable with gh. But what you suggest is also useful, it depends how far we want to go.


gh pr checks allows to see the checks for a given PR but only lasts the CSCS-CI check if it is triggered and it is only for PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

3 participants