|Title||Open edX Releases|
|Author||Ned Batchelder <email@example.com>|
|Resolution||Original pull request|
Open edX is packaged occasionally into releases. This document details the process.
Open edX releases happen roughly every six months. EdX engineers are typically focused on the much more frequent edx.org releases. This document standardizes aspects of the release process to ensure that all involved understand and participate appropriately.
When talking about software that is part of Open edX, there are a number of components that might be useful to discuss, of various sizes:
Components in Open edX are either included or supported in a release.
To be included in an Open edX release, a component must meet these criteria.
Beyond inclusion, to be supported in an Open edX release, a component must meet further criteria:
Many of these criteria are open to interpretation, or varying degrees of effort. For example, what does “documented thoroughly” mean? We can’t quantify that. It and other loose criteria are included here because they are important parts of providing a finished quality product, and we don’t want to overlook them.
Our software is built atop other software layers supported by their creators. It’s important to consider the support windows for those layers when choosing which version to use. An Open edX release is supported by edX until the next release, so for about six months. The supporting layers must be supported by their developers for the entire Open edX release.
Typically this means choosing Long Term Support (LTS) versions of the supporting layers, but it’s possible shorter-term support versions will provide the support needed.
The layers in question here are Django, Python, and Ubuntu. Here’s a calendar of the known support windows and how they overlap with Open edX plans.
A new release line is created roughly every six months. Release lines are named with words in alphabetical order: Dogwood, Eucalyptus, Ficus, Gingko, and so on. On a release line, there will be a handful of releases. The first is called .1 (Eucalyptus.1 for example). Follow-on releases are numbered from there: Eucalyptus.2, Eucalyptus.3, and so on.
After the .1 release, new releases in a line are made only for severe problems such as security problems, data loss, or feature breakage.
A new release line is created by making a “release master” branch in each involved repo. These are named “open-release/RELEASENAME.master”. This branch will be where changes are accumulated to create each release in the line. Releases will be tagged “open-release/RELEASENAME.1”, “open-release/RELEASENAME.2”, and so on.
OEP-2 defines a file format for repository metadata. The
openedx-release key is an optional dictionary governing the participation
of the repo in the Open edX release process.
Repos for applications and IDAs that are part of the Open edX software need to
openedx-release key. Libraries that are part of Open edX do not
need the key, because they will be pulled in by whatever component uses them as
openedx-release: dictionary (optional)
- The name of the release-from branch in this repo. This is the branch that will be tagged when an Open edX release is made.
- This key is obsolete, and can be removed.
- This key is obsolete. It was used by libraries. Repos marked with this key should have the entire
Open edX provides a few supported installation methods, explained below. Currently, none of the supported installation methods are intended for production. Running production servers requires making many choices based on factors such as expected load, budget, and expertise.
Our installations are based on Ansible playbooks. Up until the Eucalyptus release, all supported installation methods were single-machine: all of the Open edX software was installed and ran on a single machine, either a Virtualbox image, or a native machine.
That model does not scale up as the number of services and applications grows. Newer services are supporting Docker for installation. Eventually, we would like the supported installation methods to be based on an all-Docker model where an installation is just a constellation of Docker containers.
To allow us to move gradually from a single-machine model to an all-Docker model, we’ll support a machine running a number of edX services and applications, and also running a number of Docker containers.
There are two supported installation methods:
In Ginkgo and before, there was a third installation method, called Fullstack. This was similar to the native installation, but ran under Vagrant. There was no conceptual difference between Native and Fullstack, so we dropped Fullstack. If adopters want to run the Native installation under Vagrant, it is not hard to do.
The devstack installation is Docker-based and follows OEP-5.
We haven’t determined how best to allow developers to configure which services to run and which should be editable.
The native installation will use an Ansible playbook to install Open edX components onto the machine.
We will update this OEP later with specifics of the playbook used.
2018-08-22: Installation details adjusted to match current Hawthorn realities.