...

3d. Announce the creation of the Open edX release branch

For a 2U person to do: Send an email to edx-tech-announce@2u.com explaining that the open-release branch has been created from an edx.org release.  Here's an Make a forum post announcing that the branches have been cut and explaining what that means. For example:

Hey everyoneOpen edX developers,

TL;DR: We are now in the pre-release phase for the next Open edX release: Palm. Code merged to master now will not be part of Palm.  Keep this in mind as you make changes to master, especially needed fixes: They will need special attention, so reach out.

What is Palm?  The next Open edX community release is named Palm.  It will be based on the code as of today.  We can include your future changes if you alert us to them.  

What happened: Today we created the open-release/palm.master branches in our repos.  As of now, your day-to-day work is contributing changes you merge to master will contribute to the release after Palm after Palm, which will be called Quince. The community will be stabilizing and testing Palm, and we'll be making fixes on the Palm branches, leading up to the official Palm release in early June.What you should do

What you should do: As you do your workmerge PRs to master, please be aware of fixes that might need to be applied to Palm. I can help get the fix into the release, but you need to let us know there Let the Build-Test-Release Working Group know if there is a fix to be applied. They will need to be cherry-picked to ship as part of Palm, a.k.a. “backported”.

I know this gets confusing, but your code going onto master will now automatically be part of the Quince release (due next December). There is a new Quince wiki page for you to note things that will need to be considered when it comes time to release Quince. Please add features, caveats, and concerns to that page. If you are uncertain whether something should be mentioned there, add it. Or, talk to me and wethe Build-Test-Release WG and we'll figure it out.

Have questions? If you want to know more, we have an FAQ about the Open edX community releases.  Please reach out if you have any questions.

Thanks for all your hard work!  You make Open edX software the valued open source platform it is!

--Ned, on behalf of the community Build/Test/Release working group.

3e. Announce upcoming release to the community

Create a topic in the Announcements - Releases category on discuss.openedx.org. ((Add some boilerplate here))

If you created a pre-release branch, you should probably not write a post in “Releases” but in the build/test/release working group category. (see for instance this announcement)

Please notify the DEPR working group in the #wg-depr-slash-n-burn channel in the Open edX Slack, so that the DEPR working group can help write release notes of deprecated code in accordance with the DEPR Release Notes Process .

3f. Get the test process started

...

What’s next? From now until the Palm release date, the Build-Test-Release group will be actively testing the release branch, finding bugs, triaging them, merging fixes to master, and backporting them to Palm. The Build-Test-Release Testing Coordinator will be kicking off this process soon, and they are happy to take volunteers to find and fix bugs. Keep an eye out if you’re interested. Even if you don’t actively participate, you can help this process by promptly reviewing any bugfix PRs that are made in your repositories.

Have questions? If you want to know more, we have an FAQ about the Open edX community releases.  Please reach out if you have any questions.

--Ned, on behalf of the community Build/Test/Release working group.

Please x-post the announcement to the DEPR working group in the #wg-depr-slash-n-burn channel in the Open edX Slack, so that the DEPR working group can help write release notes of deprecated code in accordance with the DEPR Release Notes Process .

3e. Get the test process started

Reach out to the Build-Test-Release Testing Manager to make sure they’re kicking off the testing process for the newly cut release.

When they have a test plan ready, add it to Open edX Release Testing.

...

3f. Get the community-supported distribution release process started

Immediately inform the maintainers of community-supported distribution that the upstream release tags have been created and that the distribution release can proceed.

...

Update the pull request template in the master branch of edx/edx-platform to encourage developers to contribute bugfixes back to both the upcoming & next release branches (see for instance this PR).

🎁 Tagging a release or release candidate (Tagging Numbered Releases)

Releases are tags marking specific versions of all the repos.  Take care with the steps to create and tag these.  It's surprising, but you have to edit files to refer to the tags before you can create the tag.

There are two types of tagged releases:

• the major release (zebrawood.1) and

• the minor (“point”) releases (zebrawood.2, zebrawood.3, and sometimes zebrawood.4+).

The steps below apply to both major & minor releases, unless they say (major only).

1. Prepare for the tagging a week before it is scheduled….

1a. Schedule a release ceremony

Schedule a meeting for the day of release, including:

• The release manager (you!)

• At least one other Build-Test-Release WG member to check your work, take notes, etc.

• If necessary, someone from Axim to grant permissions (see “Overview / Release Manager Permissions” section).

• Anyone else who wants to listen in!

Ask someone from Axim to put it on the community working groups calendar.

1b. Double-check that the test plan is complete (major only)

Go to the Test Plan spreadsheet and check whether testing has been sufficiently completed (to the discretion of the release manager).

1c. Double-check that all known issues have been addressed

Prior to making a release (major, minor, or even a candidate), it is imperative that all known issues be fixed. You can check at the GitHub Project board with an appropriate filter such as “label:bug milestone:lilac.1”. Over time other labels or milestones may be incorporated, but just keep in mind that issues such as an uninstallable tag are unacceptable.

Search for open pull requests against the release branch. For example, for Nutmeg, we would search: https://github.com/pulls?q=is%3Aopen+is%3Apr+base%3Aopen-release%2Fnutmeg.master+archived%3Afalse.

1d. Create a wiki pages for release process notes

Create a child of this page for your own notes: Open edX Release Manager Notes

Example: Olive.1

2. Hold a release tagging ceremony

2a. Make a test branch (not a tag!)

To test the installation, but not yet mark the release, we'll make a test branch.  The branch should use your personal prefix ("you/"), and be named for the release you are working on, but with an additional .n suffix.  Don't use the full release name, or people will find the branch and think it is a release:

tag_release --doit --branch --skip-invalid --search-branch open-release/zebrawood.master --override-ref open-release/zebrawood.master you/test/z.1rc1.1

The .1 suffix is so that you can make a .2 if something needs to be fixed.

2b. Create release the Transifex project

2b1 Double check the openedx-translations repository branch

Go to the https://github.com/openedx/openedx-translations repository and ensure it has the proper release branch e.g. you/test/z.1.

2b2 Clone the openedx-translations Transifex project

After cutting the release e.g. zebrawood a new Transifex project should be copied into a new project.

• Create a new Transifex project: openedx-translations-zebrawood

• Copy the resources from the old project (How to do that without ?)

2b3 Configure the GitHub Transifex App

This is a manual step:

...

Go to the Zebrawood Transifex project configuration settings

...

In the Integrations tab, click on the GitHub App integration “Manage” button

...

Click on the three dots ... menu → the Settings button

Configure the project integrations settings from the main/master project (https://github.apps.transifex.com/projects/o:open-edx:p:openedx-translations/openedx/openedx-translations):

...

Select repo step:

• Selected repository: openedx/openedx-translations

• Selected branch: you/test/z.1 or release/zebrawood

...

Select files step:

• Add a path to your YAML configuration file: transifex.yml

...

Sync content step:

• PULL CONTENT: Fetch content automatically

• PUSH CONTENT: 100% reviewed

• How would you like Transifex to push translations to GitHub? Create a Pull Request and No grouping

• Add a prefix to the commit message: chore:

...

6. Create the release Transifex project

6a Double check the openedx-translations repository branch

Go to the https://github.com/openedx/openedx-translations repository and ensure it has the proper release branch e.g. open.release/zebrawood.master.

6b Clone the openedx-translations Transifex project

• Create a new Transifex project: openedx-translations-zebrawood.

• Add all the languages from the openex-translatiosn Transifex project.

6c Configure the GitHub Transifex App

This is a manual step:

• Go to the Zebrawood Transifex project (openedx-translations-zebrawood) configuration settings

• In the Integrations tab, click on the GitHub App integration “Install” button

  • Allow the integration

  • Grant permission to your account

  • Grant permission to the openedx/openedx-translations repository

• Continue the wizard to configure the project integrations to the following:

  • Select repo step:

    • Selected repository: openedx/openedx-translations

    • Selected branch: Set it to the release branch e.g. open.release/zebrawood.master

  • Select files step:

    • Set the path to your YAML configuration file to transifex.yml

  • Sync content step:

    • PULL CONTENT: Fetch content automatically

    • PUSH CONTENT: 100% reviewed

    • Set “How would you like Transifex to push translations to GitHub?” to Create a Pull Request and No grouping

    • Add a prefix to the commit message: chore:

  • Click on the Update Settings button

  • Wait for the sync to complete. It takes about an hour.

  • ☑️ Ensure that all the resources has been added.

6d Update the Transifex resources names and tags

The GitHub Transifex App integeration puts an inconvenient names for resources like "translations..frontend-app-something..src-i18n-transifex-input--main" instead of "frontend-app-something".

This can be fixed with the following command locally:

git clone https://github.com/openedx/openedx-translations.git
cd openedx-translations
mkvirtualenv openedx-translations
pip install -r requirements/requirements.txt
# Dry run the name fix
make TRANSIFEX_PROJECT_SLUG='openedx-translations-zebrawood' fix_transifex_resource_names_dry_run
# If runs without errors, run the actual command:
make TRANSIFEX_PROJECT_SLUG='openedx-translations-zebrawood' fix_transifex_resource_names

🎁 Tagging a release or release candidate (Tagging Numbered Releases)

Releases are tags marking specific versions of all the repos.  Take care with the steps to create and tag these.  It's surprising, but you have to edit files to refer to the tags before you can create the tag.

There are two types of tagged releases:

• the major release (zebrawood.1) and

• the minor (“point”) releases (zebrawood.2, zebrawood.3, and sometimes zebrawood.4+).

The steps below apply to both major & minor releases, unless they say (major only).

1. Prepare for the tagging a week before it is scheduled….

1a. Schedule a release ceremony

Schedule a meeting for the day of release, including:

• The release manager (you!)

• At least one other Build-Test-Release WG member to check your work, take notes, etc.

• If necessary, someone from Axim to grant permissions (see “Overview / Release Manager Permissions” section).

• Anyone else who wants to listen in!

Ask someone from Axim to put it on the community working groups calendar.

1b. Double-check that the test plan is complete (major only)

Go to the Test Plan spreadsheet and check whether testing has been sufficiently completed (to the discretion of the release manager).

1c. Double-check that all known issues have been addressed

Prior to making a release (major, minor, or even a candidate), it is imperative that all known issues be fixed. You can check at the GitHub Project board with an appropriate filter such as “label:bug milestone:lilac.1”. Over time other labels or milestones may be incorporated, but just keep in mind that issues such as an uninstallable tag are unacceptable.

Search for open pull requests against the release branch. For example, for Nutmeg, we would search: https://github.com/pulls?q=is%3Aopen+is%3Apr+base%3Aopen-release%2Fnutmeg.master+archived%3Afalse.

1d. Create a wiki pages for release process notes

Create a child of this page for your own notes: Open edX Release Manager Notes

Example: Olive.1

2. Hold a release tagging ceremony

2a. Make a test branch (not a tag!)

To test the installation, but not yet mark the release, we'll make a test branch.  The branch should use your personal prefix ("you/"), and be named for the release you are working on, but with an additional .n suffix.  Don't use the full release name, or people will find the branch and think it is a release:

tag_release --doit --branch --skip-invalid --search-branch open-release/zebrawood.master --override-ref open-release/zebrawood.master you/test/z.1rc1.1

The .1 suffix is so that you can make a .2 if something needs to be fixed.

2c. Test the release one last time

...