The Open edX codebase changes rapidly. When people deploy a new instance from the latest version of the codebase, each person ends up with slightly different code, making it difficult to share knowledge and improvements. To solve this problem, edX is creating a series of named releases of the Open edX codebase. These named releases will provide stable points in time for people to cluster around, so that it’s easier to talk about your Open edX installation and benefit from the Open edX community.
Today we released Aspen, the first named release for Open edX. Aspen is an instance of the Open edX codebase frozen at a stable point in time (mid-September 2014); the code in Aspen will not change, even as the Open edX developer community continues to build on the current Open edX codebase. All releases will receive extensive testing both from edX, which will use the release to support millions of users, as well as by organizations within the Open edX community, where the release will have been run and tested in many different configurations. We’ve picked a tree-based naming scheme: the next named release will be named Birch, and should be arriving in a few months.
The DevOps team at edX has previously released a series of Vagrant boxes following a bread-based naming scheme, with releases such as Injera and Kifli. The major difference between the bread-based releases like Kifli and the tree-based releases like Aspen is that the former is meant for developers who want to get up and running on the latest version of the codebase, whatever it might be, while the latter is meant for operators who want to have a stable, consistent version of the codebase. Bread-based releases are releases of the configuration repo only, while tree-based releases are releases of the entire edX platform. Note that this means that operators who want to switch from a Kifli-based installation to an Aspen-based installation could actually be downgrading their codebase, switching from the latest development codebase to an older, more stable codebase.
Kifli (and all configuration repo releases) is designed to track the latest version of the codebase, whatever it may be, so it can be difficult to predict what errors you may run into when trying to switch from Kifli to Aspen; different people will be starting at different versions, so they may run into different errors as they switch versions. This difficulty is precisely the reason we created Aspen: because Aspen is code captured at a stable point in time, everyone getting started with Aspen will have exactly the same codebase, and it will be easier to apply improvements and upgrades in the future. When we release Birch, we will also release a stable upgrade process to upgrade your system from Aspen to Birch without having to start from scratch again.
The code that makes up the Aspen release has been battle-tested and is ready for production usage. However, the “devstack” and “fullstack” installation scripts and documentation are designed for development and ease of use rather than for production usage. If you are planning to build a robust website for production usage, you should investigate other installation options.
Further documentation about the stable named releases is available on our Open edX Confluence pages, and more detailed installation instructions are available on the Github wiki for the configuration repository. If you run into problems, we encourage you to check the openedx-ops mailing list and join the discussion. We would love your feedback about this process so that we can continuously improve. Thank you for being an awesome and engaged community!
