Versions Compared

Old Version 230

changes.mady.by.user Kyle McCormick

Saved on

compared with

New Version 231

changes.mady.by.user Maksim Sokolskiy

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • the major release (zebrawood.1) and

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

...

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 nowno"w, and “Zebrawood” to be the next release after that (six months from now).

...

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.

...

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.

...

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

7. (For the final release) Something something translations

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

Code Block
$ paver i18n_release_push

...

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

🔢 Point 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.

...

/blob/master/.bashrc
GIT_PAGER=cat gittreeif origin/open-release/hawthorn.master log origin/open-release/zebrawood.

...

master ^origin/master