First draft at release process

[quentinlesceller]

Link to rendered markdown

Create a new release_process.md file at the root of the repository with all the steps to follow for every release.

[j01tz]

Great idea! This should definitely help improve the release process.

A few thoughts/questions:

• Is it possible to make the checksum validation and review process before merging to the site more explicit?
• Does it make sense to include a step to check to ensure that there are no dependencies that need to be upgraded as the result of an upstream security fix or would that be out of scope for the release checklist itself?
• Maybe the above points could be condensed to a 'manual/security review' step that includes multiparty manual checksum verification/review as well as a brief manual dependency review which could be extended over time with more automated tests like fuzzers etc

[lehnberg]

Great initiative @quentinlesceller, I'm all for this! 👍

Some ideas:

• How about this document becomes a more specific release_process.md, containing instructions, steps, and meta-data related to our release process, without containing an actual checklist itself? I think the steps you have already outlined is good enough for a first take; and then
• What if we manage the checklist for each release as individual GitHub issues under grin-pm? We could set up a custom issue template for a "Release checklist" that has all the checklist boxes pre-configured, and have a new issue created for every release that we can tick off boxes against. It could have a specific Release Checklist label, be assigned to team members, and be closed once completed.

Wdyt?

[quentinlesceller]

@joltz

Does it make sense to include a step to check to ensure that there are no dependencies that need to be upgraded as the result of an upstream security fix or would that be out of scope for the release checklist itself?

This is a very good question but IMO that should be handled before the release (so it does not break anything)

Maybe the above points could be condensed to a 'manual/security review' step that includes multiparty manual checksum verification/review as well as a brief manual dependency review which could be extended over time with more automated tests like fuzzers etc

I think this is the direction I'd like to go definitely 👍

@lehnberg

How about this document becomes a more specific release_process.md, containing instructions, steps, and meta-data related to our release process, without containing an actual checklist itself? I think the steps you have already outlined is good enough for a first take;

Agree modified the document accordingly.

What if we manage the checklist for each release as individual GitHub issues under grin-pm? We could set up a custom issue template for a "Release checklist" that has all the checklist boxes pre-configured, and have a new issue created for every release that we can tick off boxes against. It could have a specific Release Checklist label, be assigned to team members, and be closed once completed.

Good idea, that would be neat 👍

[quentinlesceller]

I just added three requested parts:

• The branching part and the maintenance branch along with proper versioning for grin and grin-wallet
• Website blog announcement
• Forum blog post

Am I missing something @lehnberg ?

[lehnberg]

👍 SHIP IT 🛳