Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

What is an Open edX Release?

Every six months, we take a snapshot of our code, test it, and package it as an official Open edX release - this is a stable, tested version of our code that we encourage operators to install on their systems. Releases are named alphabetically with tree names. Aspen was released in September 2014; Palm was released in June 2023. After Palm was Quince, Redwood, and so on.

Current Open edX Release Info

The current release is Quince!

🧑‍🏫 To learn about our new features, see the Product Release Notes! - Note, Product Release Notes were not produced for Quince, but some items were highlighted in Quince blog posts. The Operator Notes discuss feature changes, as well.

👩‍💻 For site operators looking to upgrade to the current release, see the Operator Release Notes.

Site operators should also be aware of our Open edX Release Schedule ; for info on previous releases, see older release branch & tag information.

Upcoming Open edX Release Dates

Our next release is Redwood!

đź“… Important Dates đź“…

✂️ Release will be cut May 9, 2024

🧪 Testing will occur May 10 - June 5

🧙‍♂️ Redwood goes out June 10, 2024

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

👷‍♀️ Curious about what’s happening in our upcoming releases? Check out our Product Roadmap.


Upcoming Release Product Management

Are you a product manager or otherwise involved in defining and creating product information for the upcoming release? Here’s some resources for you.

Upcoming Release Engineering & Build Mgmt

Are you a code engineer, a member of Build/Test/Release (BTR), or looking to help test the upcoming release? Here are some resources for you.


Wait, how do I fit into the Release process?

Everyone in the community is affected by the release process, from the people who define and develop new features and functionalities to those who deploy and use the new versions of the Open edX software.

End Users/Stakeholders

Are you a decider for your institution, do you create courses on an Open edX instance, or do you operate/administer/maintain such an instance? Then you’re one of the Open edX “end users”. We think you’ll find our Product Release Notes and/or our Operator Release Notes (top left box) most useful. If you have any questions, we invite you to participate in our community and post your thoughts and questions on the Open edX forums.

Release Team

The release team is primarily members of the Product Working Group and the Build-Test-Release (BTR) Working Group. The PWG creates the Product Release Notes, defines the ways we’re testing the release, and helps to coordinate the group of volunteer testers. We’d love to get more people involved in testing the release - if you’re an Open edX End User, you’re perfect for the job. Reach out to us the #wg-build-test-release Slack room or by attending a BTR working group meeting.

The BTR Working Group operationally runs the release - this includes doing the work to properly tag code in GitHub, and creating/configuring the testing instance we use. BTR is instrumental in coordinating testing and writing the Operational Release Notes, which are aimed at explaining to site operators how to turn on/off new features, handle tricky migrations, describe recent and upcoming code deprecations, and more.

Important dates for the upcoming release are described in the top right box, and wayfinders for various important resources are in the lower boxes.

Product Delivery Team

The Product Delivery Team is comprised of the various product managers, UX/UI designers, and developers who create new features, fix bugs, and ensure the platform has a consistent and up-to-date codebase. Product Managers primarily author the Product Release Notes, with assistance from all others who helped build the product. Product Managers and UX/UI designers also participate in the Release Testing, ensuring new features work properly and no regressions have been introduced to existing features. Developers are instrumental in authoring and merging fixes for bugs found during the release testing process.

  • No labels