TRIVIAL: Update release instructions

[ximinez]

High Level Overview of Change

Updates CONTRIBUTING.md documentation to introduce a new workflow that avoids code freezes. Also adds a few helpful scripts that can be used in by maintainers in branch management, and a CI job to check that code is consistent across the three main branches: master, release, and develop

Context of Change

The current workflow can be confusing. This new workflow is a little more complicated, but has simpler basic rules:

• No code freezes in develop.
• Push up. develop to release to master.
• The branches proceed independently when needed.
• Reverse merge down. master to release to develop.

The changes are in two commits:

• The first is a straightforward move of one chunk of CONTRIBUTING text from the middle of the file to the end.
• The second introduces all the changes.

This is intended to make the changes easier to review. The PR will be squashed into one commit when merged to develop. The second commit message should be used when merging.

Type of Change

• Documentation update
• Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
• Release

Test Plan

No code changes, so nothing to test there.
One new CI job. Ensure it passes.

Future Tasks

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.0%. Comparing base (eac3abd) to head (044a0a7).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5215     +/-   ##
=========================================
- Coverage     78.0%   78.0%   -0.0%     
=========================================
  Files          789     789             
  Lines        66951   66951             
  Branches      8107    8110      +3     
=========================================
- Hits         52216   52210      -6     
- Misses       14735   14741      +6     

see 2 files with indirect coverage changes

[bthomee]

This is looking great so far. I do want us to see if we can automate the many commands required to make a (beta) release (candidate), for instance by putting together a GitHub release bot or an interactive API script that does the heavy lifting and waits for any manual steps to complete.

[bthomee]

Friendly reminder to address these TODOs 🙂

[ximinez]

I wanted to ensure there was at least one run showing that the job worked.

[bthomee]

Do you have any guidelines for when squash and merge isn't possible and pushing as more than one commit is necessary? Is it fair to assume that the squash and merge button will be disabled when such a situation arises?

If it is not intuitive to know when pushing as more than one commit (or following another approach) is required, it would be worthwhile to add in which cases it has to be done.

[ximinez]

The default is squash and merge. The author can request to do separate commits if they think it's worth it. Some examples are where file layout is restructured, or if the commits are changing truly independent things such that they could be separate PRs, but they're pulled together in one PR under a common theme or issue.

I'l rewrite this section to reflect that.

[bthomee]

This can be disabled at the repo-level, in Settings -> General and scroll down to Pull Requests, see screenshot.

Disabling the "Create a merge commit" or "Rebase and merge" at the repo-level seems compatible with these instructions, since releases are never done via the UI - thoughts?

Note that these settings currently cannot be configured at a branch-level, although GitHub is finally working on it and it's already available in Preview, see here. If configuring these settings at the repo-level isn't acceptable, do you know if Preview is enabled for this repo, what the consequences are for enabling it, and if it's then worthwhile setting up repository rules for the develop branch?

[ximinez]

They are disabled in that section. I'll reword this.

[ximinez]

Marking this as "Trivial" because it has no effect on the rippled binary or other code, and so only needs one review, unless there are objections.

[ximinez]

Proposed commit message:

Update branch management and merge / release processes  (#5215)

* Has more steps, but allows merges to develop to continue when a
  beta / RC is pending, increasing developer velocity.
* Add a CI job to check that no reverse merges have been missed.
* Add some useful scripts in bin/git:
  * Set up upstreams as expected for safer pushes
  * Squash a bunch of branches
  * Set the version number