You want to propose a change for a community release. This means applying a change to the release branch, There are few different scenarios here.

Making a change that also belongs on master (a “backport”)

...

• The change has already been made on the master branch, and you need to copy it to the release branch.

• The change shouldn’t be made on the master branch, it is special to the release branch

If a change should be on master, then it should be made (and deployed) there first, then applied to the release branch.

...

Most changes to named releases should also be represented on the master branches. When a change is needed in a named release, the standard process it to make the change to master first, and then port the change back to the named release (hence the term backport).

The exact mechanics of backporting depend on whether you’re merging to a top-level repository (signified by the presence of a open-release/XXX.master named release branch) or a library repository (which is installed into the release by Pip or NPM and thus doesn’t have a named release branch.

Backporting to a top-level repository

1. Ensure the change is already merged to master.

2. Find the commit hash(es) of the fix you need from master. They might be the same as in the fix pull request you are copying from, or they may be different if the pull request was closed with a squash. The best thing to do is to update your master branch, and get the hashes shown in your local git log:
   $ git log

3. Check out the release branch:
   $ git checkout open-release/XXX.master
$ git pull

4. Make a new branch from the release:
   $ git switch -c <YOURNAME>/<BRANCHNAME>

5. Cherry-pick the commits onto your branch. Do this for all your commits:
   $ git cherry-pick -x <COMMITHASH> ...

6. Push your branch:
   $ git push -u origin HEAD

7. Make a pull request from your branch, using open-release/XXX.master as the base. In your pull request description, mention the original pull request on master that you are copying, if you can.

8. Tag people for review. The pull request will be handled and merged like any other.

Backporting to a library repository

1. Ensure the change is already merged to master and released to PyPI/NPM.

2. Identify the top-level repository(s) that install this library – searching the package name in GitHub search can help. We’ll call these the dependent repositories.

3. Check whether the library has a backports branch already for this release: git log XXX-backports (where XXX is the release name). If so, jump directly to “Cut a backports release”.

4. Determine whether you can simply upgrade the named release to use the latest version of this library.

   1. For each dependent repository, identify the version of the library that is used on open-release/XXX.master – we’ll call that version A. If different versions of the library are used across top-level repositories, take the smallest A.

   2. Identify the latest version of the library, which should have your change on it. Let’s call it B.

   3. Look at the changeset between A and B. You can do this with GitHub: https://github.com/openedx/<library_repo>/compare/<A>...<B>.

   4. Do you feel comfortable backporting that entire changeset to each dependent repository in the named release?

      1. If so, then open a PR in each dependent repository to upgrade the library to the latest version & tag people for review. You’re all set.

      2. If not, continue on to “Cut a backports release”.

5. Cut a backports release:

   1. Find the commit hash(es) of the fix you need from master. They might be the same as in the fix pull request you are copying from, or they may be different if the pull request was closed with a squash. The best thing to do is to update your master branch, and get the hashes shown in your local git log:
      $ git log

   2. In the library repository, check out or create the backports branch:
      $ git switch XXX-backports && git pull # if the branch already exists
$ git switch -c XXX-backports && git push -u origin XXX-backports # if it doesn't

   3. Create your own branch, based on the backports branch:
      $ git switch -x <YOURNAME>/<BRANCHNAME>

   4. Cherry-pick the commits onto your branch. Do this for all your commits:
      $ git cherry-pick -x <COMMITHASH> ...

   5. Push your branch:
      $ git push -u origin HEAD

   6. Make a pull request from your branch, using XXX-backports as the base. In your pull request description, mention the original pull request on master that you are copying, if you can.

   7. Tag people for review. The pull request will be handled and merged like any other.

If the change is being copied from master

If the change is special to the release

If your change should only be made on the release branch, there is nothing special to do. You make a change and create a pull request. The only difference is that the base of the pull request should be open-release/XXX.master instead of master. Explain in your pull request description why this should be a release-only change and doesn’t apply to master.