The deployment changes sparked a broader discussion about release management processes. Several questions needed addressing: whether two releases per year was the right cadence, whether an LTS (Long Term Support) release model should be adopted, and how to handle expand-and-contract database migrations with potentially longer gaps between releases.
Strong arguments were made for more frequent releases, suggesting that everything pointed toward a faster release pace. More frequent releases would reduce the size of changes in each release, making internal fork management easier since organizations wouldn’t be working against code from 6 months ago. Release frequency similar to other open source projects—somewhere between weekly and monthly—would be appropriate. It was emphasized that it was more important to be able to fix issues quickly than to prevent all bugs beforehand, and that more frequent releases would help with security patches.
Support was expressed for this perspective, noting that smaller deltas between releases and exercising the deployment process more frequently would strengthen organizational capabilities. More frequent releases might also eliminate the need to backport security patches between major releases.
Questions were raised about whether the vision was for point releases within an LTS model or for a strategy with many releases per year. Clarification was provided that the thinking was toward the latter, suggesting one minor release per week to per month was typical for open source software, though weekly might be too frequent for Open edX.
Important concerns were raised about adoption rates. Even with two releases per year, community members often requested less frequent releases. Introducing an LTS model might result in everyone following only the LTS releases, effectively reducing update frequency rather than increasing it. Questions were posed about how the community could ensure significant adoption and upgrade rates, suggesting this might require making releases easier or implementing some form of auto-updates.
Responses noted that a particular deployment tool could help address this, making it easier to notify users of new versions and potentially send emails to users. The satisfying experience of clicking an upgrade button (like in other content management systems) was contrasted with the current anxiety-inducing stop-the-world Open edX upgrade process. If upgrades were smoother, with more frequent releases containing smaller changes, people would be more likely to upgrade rather than viewing it as a risky endeavor.
Further support was expressed for tools to reduce upgrade anxiety, such as dry run capabilities or better feedback about whether an upgrade would succeed. Organizations were currently anxious about the next major release because they wouldn’t know about potential downtime or issues until very close to the actual upgrade.
Agreement was expressed about the goal but noting diminishing returns for centralized testing, as instance-specific configurations could cause failures that centralized tests wouldn’t catch. However, work on optimizing upgrades in one deployment method would provide valuable lessons applicable to other deployment approaches as well.
A proposal was made to find someone with release management experience from outside the community, ideally from a large, complicated open source project, who could review Open edX’s current processes and make proposals for improvement. A task force would also be constituted to work on this topic.
