Versions Compared

Old Version 178

changes.mady.by.user Ned Batchelder

Saved on

compared with

New Version 234

changes.mady.by.user Kyle McCormick

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel
panelIconId1f6a7
panelIcon:construction:
panelIconText🚧
bgColor#FFFAE6

This page could use several updates, including:

Contents

Table of Contents

🏙️ Overview

This document explains how to make an Open edX release. In this document, I'll use "zebrawood" for the release you are making, and "yucca" for the previous release.

Repos

Schedule

The schedule of cuts and releases is maintained here: Open edX Release Processes

Repos

An Open edX release is comprised of specific versions of many repos.  The participating repos all exist in the openedx GitHub organization and are determined by examining the OEP-2 openedx.yaml files in each repo. In other words, every repository that has an openedx.yaml file in its root may or may not participate in the release, depending on the contents of the file. In particular, this line needs to be present:

...

To make the process practically feasible, a tag_release.py script exists in https://github.com/edx/repo-tools . In short, on each run it will discover which repositories are eligible for a release by listing all repos in the configured organizations (the default is edx, edx-ops, and edx-solutions) and examining their respective openedx.yaml files. If a given repository is indeed eligible, the script will execute the requested branching or tagging operation on it.

Release Manager Permissions

To be able to run tag_release.py successfully, the github account in use must have write access to all the repositories that are eligible for release. For community release managers, this can be done by adding them to the community release managers team in the edX GitHub org.

Alert other teams

Other teams will want to know that you are about to make a new release branch.

T&L team/edx-platform owners

edx-platform Jenkins jobs that need to be updated for new release branches:

Have a GitHub org admin protect the new branch from accidental deletion and require the new Jenkins jobs to pass on PRs against it.

Making the release branches

A week before the release…

Run the tag_release script; if it outputs “*** edx/somerepo has openedx-release 'maybe', skipped” lines, then you should get in touch with the repo owners and ask them if they should be included in the release. If yes, then the maybe: true line should be removed from the openedx.yaml file in the repo. (see for instance this pull request).

Testing before creating release branches

If you want to try a dry-run of the release The release manager is a position in the Build-Test-Release WG. As part of their position, they should be nominated for the Release Manager Core Contributor Role , and hopefully confirmed for the role, which allows them to be granted write permissions on every repository that is part of the release.

  • If so:

    • Before cutting or tagging any release:

      • Confirm that the release manager is, in fact, a member of the community-release-manager GitHub team. If not, have someone from Axim add them.

      • Confirm that the community-release-manager GitHub team grants write access to all the repos in the release and only the repos in the release.

  • If not:

    • Before cutting or tagging any release:

      • Invite an Axim team member to the release ceremony. They will need to add the release manager to community-release-manager add the beginning of the ceremony and remove them from it add the end.

✂️ Cutting a release (Making the Master Branches)

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

1a. Look into “maybe” repos

Run the tag_release script; if it outputs “*** openedx/somerepo has openedx-release 'maybe', skipped” lines, then you should get in touch with the repo owners and ask them if they should be included in the release. If yes, then the maybe: true line should be removed from the openedx.yaml file in the repo.
(see for instance this pull request).

1b. 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!

1c. Pre-announce the master branches

Make a post like this one in Discourse to let people know that the master branches will be created.

Get a 2U person to poke engineers inside 2U about it too.

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: Palm.master

2. Hold a release cutting ceremony

Get together on a video call. Release manager: share your screen so everyone can follow along. If everyone’s comfortable with it, record it for future reference.

2a. Pull the latest translation (Optional)

Currently the job that makes the PRs is running on Jenkins infrastructure at 2U. If a 2U engineer is available to run these jobs manually, you can ask them to do that now and merge the latest translations PRs before you cut the release branches.


- Trigger the job which pulls the translation and creates PRs (i.e. PR for fronted-app-learning: https://github.com/openedx/frontend-app-learning/pull/973 , PR for edx-platform: https://github.com/openedx/edx-platform/pull/31039 )
- If the PRs are not merged at the time (this is expected hence the above note), leave a note about them so that we can backport the commit at a later time.

Why we need to this: The point of doing this is that we ensure the shortest lag possible between the last time a translator review/translate string and the branch cut date. i.e. If the syncing happens on a weekly basis and we do the branch cut just a day before the scheduled weekly sync , then we would in theory lose 6 days of translation work.

2b. Testing before creating release branches

If you want to try a dry-run of the release before making any release branches, make a branch under your personal name. Don't use the full release name in the branch name, or people will think it's a release.  Follow the instructions for "Create the release branches", but use "yourname/test-z.1" instead of "open-release/zebrawood.master", for example:

Code Block
$ tag_release --doit --skip-repo "*-internal" --branch yourname/test-z.1

2c. Create the release branches

The repo-tools repo has a script, tag_release.py, to branch and tag the proper repos.  The repos are indicated by an "openedx-release" entry in their openedx.yaml file.  Releases before Ficus would mark dependent repos (those installed by other repos, such as XBlock being installed by edx-platform).  We no longer branch or tag dependent repos.

...

Double-check what the script did to see that it looks correct.

3. Make announcements rights after the release is cut

3a. Get release notes started

Tell your doc writer the date the release was based on.  Also find the date the previous release was based on.  They will use these two dates to comb the edx.org release notes for information to go into the Open edX release notes.

Create a wiki page for the next release

...

3b. Get the blog post started

??? Reach out to

3c. Update the release planning wiki pages

Consider “Yucca” to be the release you are cutting now, and “Zebrawood” to be the next release after that (six months from now).

Under Open edX Release Planning page has a sub-page for each release.  Make a new wiki …

  • Create a new planning page for the next release

...

Announce the creation of the Open edX release branch

Send an email to eng-all@edx.org explaining that the open-release branch has been created from an edx.org release.  Here's an example:

Hey everyone, 

TL;DR: We are in the Lilac pre-release phase. Keep Lilac in mind as you make changes. They will need to be cherry-picked to ship as part of Lilac. Koa is still the currently supported release and also might need fixes. Lilac will become the supported release in June.

What happened: On Friday, we created the open-release/lilac.master branches in our repos.  As of now, your day-to-day work is contributing to the release after Lilac, which will be called Maple. The community will now be stabilizing and testing Lilac, and we'll be making fixes on the Lilac branches, leading up to the official Lilac release in early June.

...

  • :

    • Name it Next Release: Zebrawood.

    • You can use Next Release: Yucca page as a template for the structure of the page.

  • Indicate that current planning page, Next Release: Yucca, is no longer active:

    • Rename it Upcoming Release: Yucca.

    • Add a warning that new changes should be added to Next Release: Zebrawood.

Finally, update Open edX Release Schedule .

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 example:

Hey everyone,

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, especially needed fixes: They will need special attention, so reach out.

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

What you should do: As you do your work, please be alert for happened: Today we created the open-release/palm.master branches in our repos.  As of now, your day-to-day work is contributing to the release 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: As you do your work, please be aware of fixes that might need to be applied to LilacPalm. I can do the work of getting the help get the fix into the release, but I'll need your help to know there you need to let us know there is a fix to be applied. They will need to be cherry-picked to ship as part of Palm.

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 new Quince wiki page for  for you to note things that will need to be considered when it comes time to release Maple: Maple  .  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 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)

Also send out an email to eng-all@edx.org to let everyone at edX know about the upcoming Open edX release, as well. This should remind people to update the wiki page for the release (for example this page for the Eucalyptus release). They should keep track of bugfixes that are in flight, so that when they get merged into master, they can also be pulled into the release candidate branch.

Please notify the DEPR working group in the #depr-slash-n-burn channel in the Open edX Slack, so that the DEPR working group can help 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 .

Make release-specific changes on the release branch

Some changes need to be made directly on the release branch, because they are intended for the release itself, and should not be on master.

Release line

In edx-platform/openedx/core/release.py, edit the RELEASE_LINE line to indicate the release:

Code Block
RELEASE_LINE = "zebrawood"

Translations

We upload release-specific versions of the translated strings to Transifex. This is done by editing the edx-platform/.tx/config file on the release branch. Add two clauses like this:

...

3f. 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.

3g. 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.

As of Palm, the community-supported distribution is Tutor. You can reach its maintainers by creating a thread on the forums and tagging @tutor-maintainers.

4. Make release-specific changes on the release branch

Some changes need to be made directly on the release branch, because they are intended for the release itself, and should not be on master.

4a. Release line

In edx-platform/openedx/core/release.py, edit the RELEASE_LINE line to indicate the release:

Code Block
RELEASE_LINE = "zebrawood"

4b. Translations

We upload release-specific versions of the translated strings to Transifex. This is done by editing the edx-platform/.tx/config file on the release branch. Add two clauses like this:

Code Block
[o:open-edx:p:open-edx-releases:r:release-zebrawood-js]
file_filter = conf/locale/<lang>/LC_MESSAGES/djangojsdjango.po
source_file = conf/locale/en/LC_MESSAGES/djangojsdjango.po
source_lang = en
type = PO

Make sure that the file has no other "release-" resources.

⚠ The exact syntax of this file is undetermined as of 2022-06-09. Please see this PR for more information.

Inform edx-platform developers

We should update the pull request template in the master branch of edx/edx-platform to encourage developers to contribute bugfixes back to the release branch (see for instance this PR).

Documentation

There are a few places to update documentation. Some happen when the release branches are made, others when the release is finished.

When the release branches are made

In edx/edx-documentation:

On the master branch:

Make release-specific pages for installation and release notes:

For example:

...



[o:open-edx:p:open-edx-releases:r:release-zebrawood-js]
file_filter = conf/locale/<lang>/LC_MESSAGES/djangojs.po
source_file = conf/locale/en/LC_MESSAGES/djangojs.po
source_lang = en
type = PO

Make sure that the file has no other "release-" resources.

⚠ The exact syntax of this file is undetermined as of 2022-06-09. Please see this PR for more information.

5. Update the documentation

This will require you to make a few PRs. Have them reviewed from someone else on the Bulid-Test-Release WG.

5a. Changes guide book titles for the release

In openedx/edx-documentation, open a PR and tag someone on BTR for review:

  • On the open-release/zebrawood.master branch:

    • Update the titles of three books. The titles should be changed from “<Versionless Title>“ to “<Versionless Title>: <Version> Release“.

    • Also change intro paragraphs that explain what the book applies to.

    • For example, https://github.com/edx/edx-documentation/pull/1867

    • In each book, update source/index.rst and source/conf.py

      • "Building and Running an Open edX Course"

      Find the three Open edX book projects:

    • On the open-release/zebrawood.master branch:

      • Update the titles of three books. The titles should be changed from “<Versionless Title>“ to “<Versionless Title>: <Version> Release“.

      • Also change intro paragraphs that explain what the book applies to.

      • For example, https://github.com/edx/edx-documentation/pull/1867

      • In each book, update source/index.rst and source/conf.py

        • "Building and Running an Open edX Course"

          • edx-documentation/en_us/open_edx_course_authors

        • "Installing, Configuring, and Running the Open edX Platform"

          • edx-documentation/en_us/install_operations

        • "Open edX Learner's Guide"

          • edx-documentation/en_us/open_edx_students

      • In shared/conf.py, update the “release_line” variable to have the name of the release:

        Code Block
        release_line = "zebrawood"

    On readthedocs.org, logged in as “edx”:

        • course_authors

      • "Installing, Configuring, and Running the Open edX Platform"

        • edx-documentation/en_us/install_operations

      • "Open edX Learner's Guide"

        • edx-documentation/en_us/open_edx_students

    • In shared/conf.py, update the “release_line” variable to have the name of the release:

      Code Block
      release_line = "zebrawood"

5b. Ask Axim to activate hidden release versions of each book

File an Axim systems request to do the following:

Once the release is official

Make a release or release candidate

...

5c. Add the latest release to the main docs site

In openedx/docs.openedx.org, open a PR and tag someone on BTR for review:

  • Create a new file at source/community/release_notes/palm.rst

    • Add a title to it like the following:

      Code Block
      Open edX Palm Release
#####################

  • Update source/community/release_notes/index.rst, add a new line to the toctree so it looks something like this:

    Code Block
    languagediff
     .. toctree::
    :maxdepth: 2

+    Palm: The next release <palm>
     Olive: The current release <olive>
     named_release_branches_and_tags
     old_releases

  • Update source/community/release_notes/named_release_branchs_and_tags.rst with a new section for the new release.

  • Once the PR has been created, contact the Release Documentation Expert so that they can review and merge the PR.

5d. Inform edx-platform developers via the PR template

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:

1. 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.

2. 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:

Info

Don’t create a tag for testing, because once it is pulled by other developers or processes, it becomes very hard to delete - specially on a busy repository such as edx-platform.

Code Block
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.

(TODO: update this with the saved repo list feature, instead of relying on --skip-invalid)

3. Update and upload translations on the test branch

Using a devstack on the test branch, upload the strings to Transifex with:

Code Block
i18n_tool extract; i18n_tool dummy; i18n_tool generate
paver i18n_compilejs
paver i18n_release_push

This will change .po and .mo files that will need to be committed.

4. Run through the native installation (until Lilac)

Note

Do not skip this step. This is no longer necessary now that the native installation is unsupported

No matter what CI says, and even if you have reports of the same exact git hash having been successfully tested the day before, test-install the branch before tagging it. At the time of writing, this means going through all the steps defined in Koa Native Open edX platform Ubuntu 20.04 64 bit Installation . This will avoid anything from last-minute requirements installation problems, to full-blown Ubuntu package removals.

5. Test the release

Using the native installation just produced, run through the Release Test Process to make sure there are no glaring problems.

6. Create RC or release tags

Info

Execute this step if, and only if, there were no problems up to it. It is not practical to overwrite a tag on busy git repositories. If there are any errors, a new tag will have to be created.

For each tagged repo, make tags for the release or release candidate. The tag name is different for the two:

  • Release candidate: the tag should be open-release/$RELEASE.XrcY, where X is the number of the release, and Y is the number of the RC.

  • Release: the tag should be should be open-release/$RELEASE.X, where X is the number of the release.

Code Block
tag_release --doit --tag --skip-invalid --search-branch open-release/zebrawood.master --override-ref you/test/z.1rc1.1 open-release/zebrawood.1rc1		# for release candidate
# or:
tag_release --doit --tag --skip-invalid --search-branch open-release/zebrawood.master --override-ref you/test/z.1.1 open-release/zebrawood.1				# for release

You can delete the test branches you made once the release is marked:

Code Block
tag_release --doit --branch --skip-invalid --reverse  you/test/z.1rc1.1

7. Update release directory page

Update the release page in https://github.com/edx/edx-developer-docs.

8. Announce to the community

Create a topic in the Announcements - Releases category on discuss.openedx.org.

Change the topic line in the #ops channel in Slack.

Info

Things that used to be done, but are no longer:

  • For Birch, we did both an announcement email and a post to the engineering blog. 

  • You should also create a Confluence page summarizing the status of the release candidate branch. Here's the one we used for Birch.

9. (For release candidates) Collect bugfixes, create new RCs

Over the next two weeks or so, keep an eye out for bugfixes going into master, so that important bugfixes also go into the release master branch. If there are a significant number of changes (however you want to define "significant"), you should create another release candidate. That consists of updating the Confluence page for the release candidate branch, tagging the repos, possibly creating and uploading new Vagrant boxes, testing the upgrades, and sending out another email to the community informing them of the new release candidate. If there's less than a week before the planned release date, and you're putting out a new release candidate, you should push back the planned release date so that everyone has more time to test on the new release candidate. (Be sure to announce to the community and to everyone at edX that the planned release date is being pushed back.)

The final version

(TODO: what has to happen differently for the final version?)

Run the translation commands to upload the latest text to Transifex:

Code Block
$ paver i18n_release_push

Check that release changes made it to master

During the stabilization of the release, you may have changes made directly on the open-release/zebrawood.master branch.  Take a look at what's there, and compare to master to be sure all the changes end up on master also.  Keep in mind that there are a few changes on the release branch that should only be on the release branch (RELEASE_LINE and translation naming, for example).

Code Block
# gittreeif is a handy function from https://github.com/nedbat/dot/blob/master/.bashrc
GIT_PAGER=cat gittreeif origin/open-release/hawthorn.master log origin/open-release/zebrawood.master ^origin/master

Follow-on releases

The first released version on the open-release/zebrawood.master (for example) release branch is called open-release/zebrawood.1 .   Subsequent releases use incrementing numbers: open-release/zebrawood.2, open-release/zebrawood.3, and so on.

The procedure for creating them is exactly the same as the Make a release or release candidate described above, except that you’d name test branches as you/test/z.2rc1.1, and tags would look like open-release/zebrawood.2.

OTHER STEPS TO ADD SOMEPLACE ABOVE

  • Devstack docker images have to be built (image builders?) Run on edx internal Jenkins.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:

Info

Don’t create a tag for testing, because once it is pulled by other developers or processes, it becomes very hard to delete - specially on a busy repository such as edx-platform.

Code Block
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. Update and upload translations on the test branch

Note

This step is out of date. The release manager hasn’t done this since Nutmeg or earlier. Instead:

  • For major releases: Reach out to #wg-translations and inform them that the <zebrawood>.1 has been tagged. Hopefully, someone will know what that means and help you out.

  • For major & minor releases:Régis B. has some particular steps he does with openedx-i18n as part of the Tutor release process.

This should all be replaced when OEP-58 is implemented.

For this method, you should be using tutor and should have openedx/edx-platform on the target release branch locally.

2b1. Tutor

In the case that this is a new release, it is best to use Tutor’s Nightly branch, otherwise the Master branch is recommended. Using tutor, open a shell in cms while mounting the local edx-platform repo set to the target release branch.

Code Block
tutor dev run cms bash -m path-to-edx-platform

2b2. Setup

There are some setup items that are necessary as of nutmeg [last updated 2022-09-01]:

  1. Install the development requirements

  2. Uninstall the old transifex-client (v2)

  3. Install the new transifex-client (v3)

Code Block
make dev-requirements
curl -o- https://raw.githubusercontent.com/transifex/cli/master/install.sh | bash

2b3. Transifex Credentials

Add your transifex credentials to ~/.transifexrc. Replace {TOKEN} with a token from Transifex.

Code Block
[https://www.transifex.com]
api_hostname = https://api.transifex.com
hostname = https://www.transifex.com
password = {TOKEN}
rest_hostname = https://rest.api.transifex.com
token = {TOKEN}
username = api

2b4. Generate, Compile, and Upload to Transifex

Open a new bash shell within the current shell and follow these commands to generate, compile and upload Translation files. Replace {release-version} in line 5 with the name of the release. It should match the files in .tx/config.

Code Block
bash
i18n_tool extract
i18n_tool dummy
i18n_tool generate
paver i18n_compilejs
tx push -s -r open-edx-releases.release-{release-version} open-edx-releases.release-{release-version}-js

2b5. Manually Renaming the Translations Files

In the case that this is the first time the resources are being uploaded to Transifex, log in to Transifex, find the files named django.po and djangojs.po, confirm that the slugs (check out the url) match the release version and rename the files to match the naming convention.

Code Block
djangojs.po -> release-{release-version}-js
django.po -> release-{release-version}

2c. Test the release one last time

At the discretion of the release manager, consider doing some more testing at this point.

Here’s a way you can do that:

Code Block
tutor config save --set OPENEDX_COMMON_VERSION=you/test/z.1
tutor images build --build-arg OPENEDX_I18N_VERSION=open-release/<y> openedx
tutor local launch

Where <y> is the most recent tagged release.

2d. Create RC or release tags

Info

Execute this step if, and only if, there were no problems up to it. It is not practical to overwrite a tag on busy git repositories. If there are any errors, a new tag will have to be created.

For each tagged repo, make tags for the release or release candidate. The tag name is different for the two:

  • Release candidate: the tag should be open-release/$RELEASE.XrcY, where X is the number of the release, and Y is the number of the RC.

  • Release: the tag should be should be open-release/$RELEASE.X, where X is the number of the release.

Code Block
tag_release --doit --tag --skip-invalid --search-branch open-release/zebrawood.master --override-ref you/test/z.1rc1.1 open-release/zebrawood.1rc1		# for release candidate
# or:
tag_release --doit --tag --skip-invalid --search-branch open-release/zebrawood.master --override-ref you/test/z.1.1 open-release/zebrawood.1				# for release

You can delete the test branches you made once the release is marked:

Code Block
tag_release --doit --branch --skip-invalid --reverse  you/test/z.1rc1.1

2e. Add the list of tagged repositories to the notes page

Just like this: https://openedx.atlassian.net/wiki/spaces/COMM/pages/3604807768/Olive.1#Notes

This will give BTR an answer to the question “Which repositories were tagged?”, which will certainly be asked many times.

2f. You’ve made a release!

Congrats, you’ve tagged a new Open edX release!

Now, read through the follow-up steps below, and make sure they make sense. In the next ~day you’ll either need to do yourself them or delegate them to others.

3. Kick off the community-supported distribution release

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

As of Palm, the community-supported distribution is Tutor. You can reach its maintainers by creating a thread on the forums and tagging @tutor-maintainers.

4. Update the documentation

This can happen concurrently with the Tutor Release step.

4a. Ask Axim to un-hide the release versions of each book (major only)

File an Axim systems request to do the following:

4b. Make the new release notes the “latest” (major only)

In openedx/docs.openedx.org, make a PR (example) with the following changes, tagging someone on BTR for review:

  • Update source/conf.py to point the latest release to the latest release page.

    Code Block
    languagediff
    rediraffe_redirects = {
-    "community/release_notes/latest.rst": "community/release_notes/yuca.rst",
+    "community/release_notes/latest.rst": "community/release_notes/zebrawood.rst",
}

  • Update source/community/release_notes/index.rst:

    • Change “Zebrawood: The next release <zebrawood>” to “Zebrawood: The current release <zebrawood>”

    • Remove “Yucca: The current release <yucca>”

  • Update source/community/release_notes/named_release_branches_and_tags.rst (example)

  • Add “yucca” to the list at source/community/release_notes/old_releases.rst

  • In source/index.rst change “Current Release: Yucca <community/release_notes/yucca>” to “Current Release: Yucca <community/release_notes/yucca>”

4c. Update the release planning wiki pages (major only)

Consider “Yucca” to be the release you are cutting no"w, and “Zebrawood” to be the next release after that (six months from now).

Under Open edX Release Planning …

Finally, update Open edX Release Schedule .

4d. Inform edx-platform developers via the PR template (major only)

Update the pull request template in the master branch of edx/edx-platform to encourage developers to contribute bugfixes back to the latest release branch. Drop any mention of the previous release, which is now unsupported. See for instance this PR.

5. Announce to the community

Create a topic in the Announcements - Releases category on discuss.openedx.org.

Change the topic line in the #ops channel in Slack.

5a. Announce the new named release (major only)

Make sure a blog post gets published.

Update the Support Windows chart. For example: https://github.com/openedx/repo-tools/pull/325/files. Be sure to read the top of barcalendar.py to understand how to update the chart.

Have the 2U contact announce the release within 2U. Send an email to edx-tech-announce@2u.com, for example:

The Olive release of the Open edX platform was officially released on Monday 12/12! Thanks for everything you did to help make it happen. 

This is not the end of Olive: the open-release/olive.master branches are still accepting fixes. When fixing problems in your normal course of work, please consider whether it makes sense to backport it to Olive.

I know the release process can be a bit mysterious:

- The open-release/olive.master branches were created in 44 repos on October 11th.

- Since then, all work on master or main branches has only been part of Olive if it was explicitly cherry-picked or backported.

- The master or main work since October 11th has been the start of the Palm release that will happen next June.

If you have questions, we have an FAQ wiki page about Open edX releases, and you can always reach out to us in the #interest-openedx 2U Slack channel.

Thanks again for helping make the Open edX platform available around the world to the thousands of sites using it for their online education!

--Ned.

6. Keep an eye out for bugfixes that should be backported

Over the next two weeks or so, keep an eye out for bugfixes going into master, so that important bugfixes also go into the release master branch. These will become part of the following minor release.

Generally, zebrawood.3 is the final minor release, but in cases where we have important follow-up fixes, you can tag zebrawood.4, etc.

7. (For the final release) Check that release changes made it to master

Note

I’m not sure that this step makes sense still -Kyle

During the stabilization of the release, you may have changes made directly on the open-release/zebrawood.master branch.  Take a look at what's there, and compare to master to be sure all the changes end up on master also.  Keep in mind that there are a few changes on the release branch that should only be on the release branch (RELEASE_LINE and translation naming, for example).

Code Block
# gittreeif is a handy function from https://github.com/nedbat/dot/blob/master/.bashrc
GIT_PAGER=cat gittreeif origin/open-release/hawthorn.master log origin/open-release/zebrawood.master ^origin/master