...

Periodically, we tag our repos as an official Open edX release. Releases are named alphabetically with tree names. Aspen was released in September 2014; Olive was released in December 2022. Next is PalmAfter Olive was Palm, and so on.

Details of the release schedule are at Open edX Release Schedule.

...

Why do we make Open edX releases?

• The Open edX community can share knowledge and improvements more easily when many people use the same stable, consistent version of the Open edX code.

• Open edX releases create milestones that are easier to talk about and use than the ever-shifting master branches.

• It creates a good cadence for a period of pre-release testing and bugfixing.

• It creates a reliable upgrade cadence for site operators to follow.

Is it OK that some people use master?

...

The Build - Test - Release working group is in charge of Open edX releases. If you have questions about the group, the process, or getting involved, reach out in their Slack channel or in their forum subcategory.

Ned Batchelder (ned@edx.org, or @nedbat on Slack) used to be the release manager, and helps the group now with logistical issues. Ned can also be the point of contact for internal 2U/edX people with questions.

...

We make a release every six months. In the past (pre-Juniper), releases have had to wait for an important change in the code, but we are focusing on date-based releases now. See the release schedule for details.

The Support Windows spreadsheet shows interactions among the supported versions of our dependencies.

What is

...

an Open edX release?

Individual repos from the openedx GitHub organization decide if they are part of an Open edX release by including the "openedx-release" key in their openedx.yaml file. This is also how the repo indicates what branch should be used for releases.

...

This is an ambiguous question. When ask about something “being in the Open edX release,” we need to be more specific. There are a few levels at which code/features can be in a release….

Tagged Repositories

Each release, we create a release master branch followed by 3+ release tags in various repositories. For example, in Nutmeg, we created these:

• Branch: open-release/nutmeg.master

• Tags: open-release/nutmeg.1, open-release/nutmeg.2, open-release/nutmeg.3.

in these repos:

edx/edx-e2e-tests
edx/frontend-app-communications
edx/frontend-app-ora-grading
edx/testeng-ci
openedx/blockstore
openedx/configuration
openedx/course-discovery
openedx/credentials
openedx/cs_comments_service
openedx/devstack
openedx/ecommerce
openedx/ecommerce-worker
openedx/edx-analytics-configuration
openedx/edx-analytics-dashboard
openedx/edx-analytics-data-api
openedx/edx-analytics-pipeline
openedx/edx-app-android
openedx/edx-app-ios
openedx/edx-developer-docs
openedx/edx-documentation
openedx/edx-notes-api
openedx/edx-platform
openedx/enterprise-catalog
openedx/frontend-app-account
openedx/frontend-app-authn
openedx/frontend-app-course-authoring
openedx/frontend-app-ecommerce
openedx/frontend-app-gradebook
openedx/frontend-app-learner-record
openedx/frontend-app-learning
openedx/frontend-app-payment
openedx/frontend-app-profile
openedx/frontend-app-publisher
openedx/frontend-app-support-tools
openedx/frontend-template-application
openedx/license-manager
openedx/openedx-demo-course
openedx/repo-tools
openedx/tubular
openedx/xqueue

Only main repos need to be tagged. Dependent repos, such as libraries pulled into another service as a dependency, are not tagged.

In the past, both the edx and openedx GitHub organizations were searched for repositories to tag. As of Palm, only repositories in the openedx organization are consideredThese branches and tags exist to help the Build-Test-Release working group orchestrate their testing, documentation and fixes, and they are used as input to the community deployment tools, like Tutor. A repository being tagged doesn’t necessarily mean it’s well-supported. More on that later.

To be tagged, a repository must be in the openedx GitHub organization. In order get a repository moved into the openedx organization, you can file a Axim request.an Axim request. It can then opt in to being tagged by including openedx-release: "<BRANCH-TO-RELEASE>" in their openedx.yaml file, where <BRANCH-TO-RELEASE> is typically set to master or main.

Dependent Repositories

Only top-level repositories should be tagged.

The top-level repositories inevitably depend on various dependent repositories (i.e., Open edX libraries). We do not put tags in our libraries, because those tags would often conflict with the library versions which top-level repositories specify in their requirements.txt and package-lock.json files.

More details are in OEP-10: Open edX Releases.

Features: Default, Supported, Experimental, and Unsupported

The features in Open edX are whatever features are in the repos. Feature flags and toggles can be used to turn features on and off, and the default for those toggles might be different for edx.org and for the Open edX releases, but there isn’t a separate list of what features are going into the Open edX release.tagged repositories include various features. Some features are enabled by default, whereas others need to be toggled on or configured.

The release notes, roughly, mention four tiers of features:

• 1. Default features. These features are enabled out-of-the-box when someone installs Open edX using the supported community deployment tool (as of Quince, that’s Tutor). The Build-Test-Release WG treats these features as the highest priority for testing, bugfixing, and security.

• 2. Supported features. These features may be off by-default, but the community still tests them, tries to keep bug-free, and monitors their security. The community deployment tool usually makes it easy to turn these features on (for example, there may be an official Tutor plugin available).

• 3. Experimental features. These features are moving towards being Supported, but aren’t quite there yet. Site operators can turn them on in order to get a preview of what’s coming in future releases. Bug reports are appreciated, but may not be high priority.

• 4. Unsupported features. Tagged repositories sometimes include features that the community no longer supports, or never supported. This includes features which are deprecated but haven’t yet been removed. Site operators can turn these on, but should not expect bugfixes or security patches from the community

What tags and branches are used in a release?

...