Ideal release philosophy and cadence?

We had a 17-month gap between Ironwood and Juniper. Everyone agrees this was too long.

What should we aim for? Our stated goal had been a release every six months, but some releases needed to wait for technical considerations: Hawthorn needed to upgrade to Django 1.11, taking 12 months. Juniper needed to upgrade to Python 3 and Django 2, taking 17 months. (BTW: the Support Windows calendar has some of these details.)

As we start to consider the next release (Koa), what should we be aiming for? Would more frequent releases help people stay current? Or would a (for example) three-month cycle just mean people skip every other update? Academic institutions will want to schedule updates for on-campus quite periods.

There will always be technical considerations (for example, Ubuntu 16.04 goes out of support in April '21, so we need to be sure a release on a newer Ubuntu happens before then), but ideally they wouldn’t dominate the planning.

What is your ideal?


@nedbat Having regular releases that are cut at regular times would be best imho. It would make everything more predictable. There are always reasons to cut releases later or earlier – but could we just ignore them and release things at a given time? runs off master, so it should always possible to cut a release at any point in time?

One release every 6 months would already be a good acceleration compared to the recent releases, and it could be worth targeting this as a first step? Although increasing the rate further could be an interesting experiment as a second step – the more often we’ll release, the more incentive we’ll have to streamline the process?

1 Like

At MIT Open Learning, we schedule two major releases a year to coincide with gaps in the academic calendar. So, from our perspective, a release every six months would be ideal. Even better would for them to be scheduled for April and October.

I do not have a definite opinion on feature-based VS time-based releases. The current state of Open edX releases is that we do neither: we attempt to release every 6 months and at the same time make sure that technical components are kept up-to-date, so the actual release dates vary. Thus, either choice would be an improvement.

Having releases at definite time-based intervals would be great, but I believe they would actually require more work from the Open edX community. For instance, we would have to make sure that:

  1. We are not merging half-merged features
  2. We know what actually goes into every release
  3. Technical components do not get outdated between two releases

If we do manage to resolve these questions, then time-based releases would be a great improvement.

Concerning the release cadence: my feeling is that the right frequency would be somewhere between 3 and 9 months. Releasing every 3 months would require too much work, and if we wait longer than 9 months then the diff would be too large.

I am supportive of date-based releases for all the aforementioned reasons.

I agree that a 6-month cycle would be a minimal target that is more manageable than what’s there today. I would also encourage considering targeting every 4 months (3x a year) - to help the community (1) have an ongoing cadence that doesn’t require large bursts of effort with large accumulated code and (2) leverage the latest and greatest features with more timely opportunities for contributions. The shorter cadence may not be achievable for Koa (since large Juniper will take time and effort to adopt) - but the shorter cadence could be a target for subsequent releases after Koa.

As Xavier points out, is constantly updated multiple times a day off of master. So the community need not worry as much about half-merged features. Any in-progress feature would be hidden behind feature toggles.

I’m proposing that we take Nimisha’s suggestion of a four-month release cycle. We hope that this means each release is more manageable, both to produce and to adopt.

There are implications: edX only provides security fixes for the latest release. How does that interact with a four-month release cycle? Does anything in the DEPR process need to be changed? There are probably other considerations also.


I think the move to periodical releases adds more predictability, which is great.

Assuming we went with a 4-month release period, Koa would be released in early October – in about two months. Considering that it takes roughly a month to craft a new release, this leaves us another month worth of new commits. How should we prepare? In which specific areas of the platform should we look for changes?

I like the idea of date-based released and starting with a 4-month release period from Juniper is a good challenge to take on.

In terms of areas of changes, I’m interested in anything related to MFEs. For us it would increase the velocity of experimentation around the UI/UX.

For a small team like us at EDUlib, this would put a lot of pressure on us having releases every 4 months. Because we have a fork, we would need to rebase everything and redo our regression testing almost all year long.

We would definitely not be able to follow the rhythm and would force us to stop testing new releases and be part of the BTR workgroup.

Unless patches are still available for more than the latest master and the latest open release. But then I understand clearly it would shift the problem to the edX and Open edX team who have always only supported master and Juniper for example.

I confirm Pierre remarks. 6 months between releases is as much as we can sustain and we can internally schedule them on the academic calendar.

Having a release cadence is a really nice idea and will allow us at OpenCraft to better organize our time to contribute to the new releases and to update our instances but I agree that a 4 months cadence would be challenging to follow. Going with 6 months between releases sounds more reasonable.

As a developer, a release every 4 months can be an issue for following reasons

  1. Projects usually take up to 3-4 months to develop, if releases are every 4 months, then once projects are delivered, we’ll have to upgrade them, upgrades usually come with UI and backend changes as well.

  2. The trend that I’ve seen in my clients is they generally ask for upgrades yearly or half yearly (in case of big release like ficus, hawthorn, juniper) etc, depending on project completion. Which would again take around 3-4 months of development time.

  3. It happens in our team that people are working on one release for long and skip one release, for example ginkgo to ironwood, in that case there won’t be enough time to learn about new release or be familiar with it, as there’ll be another release soon.

6 months release is a viable option.

I’m very happy with the way this discussion is going. My two cents here is that although I’d like to live in a world where we can do releases every 4 Months, getting there will be quite a hefty goal so why not start with something in the 6~9 Months range and try to keep up with this pace with at least 2 releases before we start discussing a faster cadence.

I’ll be happy about the 6 Months pace if that is what we end up doing.

The comments seem to point at a majority of people preferring a 6 months fixed release cadence, at least as a first step for now - would you agree? That would give two more months, until seem more reasonable, given that few people have done the migration for now?

Also, if we use a fixed release cadence, it would make sense to pick the next release date with this in mind, to be delibarate about the dates. To allow people to do them around vacation times, maybe Jul 1st (and thus Feb 1st) release dates would make sense?

This could be a good discussion for the release working group meeting later today :slight_smile:

1 Like

It would actually be a relief for me to go with a 6 month cadence. 3 releases a year means a lot of additional work to keep Tutor up-to-date.

Yes, this is a good timing.

This topic is not the priority of the bi-monthly WG meetup, which was scheduled to better include people both from the west and east timezones. It’s a short meetup that is designed to discuss and address technical issues with the current and the next releases. That being said, if we have extra time then yes it would make sense to discuss the release schedule. But my feeling is that it would make even more sense to discuss this important (and time-hungry) topic in a dedicated meetup. I’d be happy to help schedule it :sunglasses:

1 Like

I hear the feedback here. It sounds like six months is a better fit for people right now.

True fact: the original plan was to have timed six-month releases. OEP-10 explains the process of Open edX releases, and says they “happen roughly every six months.” We can update the OEP to be clearer about this, and perhaps pick particular dates?

@nedbat That would make sense to me. :+1: Is this still the next step? And if so, is any help needed?

I think since the OEP is already so close to our Koa goal, we can focus on getting Koa out, and use the experience to inform the next update to the OEP.

1 Like