How to keep old releases installable?

The edX support policy is that the latest Open edX release is the only one that is supported. So as of this moment, Ironwood is supported. This means that we will fix problems with installation, security, or data loss.

Hawthorn (and earlier) are not supported. Yet people still want to install those versions. What can we do when those installations stop working? @lpm0073 has opened a pull request to fix Hawthorn in light of numpy dropping support for Python 2. edX doesn’t have the resources to verify this fix, which is why we only support one version. What does the community want to do to keep old releases working?


it’d be judicious to create a community committee for any release which, like hawthorn, has both breaking changes and a base of community members who depend on the repo to continue to at least “work”.

i’d be in favor of:

  • this committee carrying out its duties under the supervision of a delegate from edX
  • the committee charter being limited to simply keeping the repo functional. that is, it would generally discourage pull requests for anything other than fixes to breaking changes in the code.

so in other words, its a committee that is staffed by the very people who depend on the repo, and, their mandate is basically to keep the repo on life support.

1 Like

Definitely not a bad idea. Unfortunately, a lot of people with experience move on from a later release to a newer release. In our case, we’re always up front or ahead of the curve as we were told from the beginning that only the newest release would be supported.

And it is not easy to keep up with prerequisites for older releases as they simply may not be accessible anymore. Not everybody can support multiple releases in order to help others.

And there are a lot of newbies or non sysadmin / non devops people who are asked to manage an Open edX instance. The learning curve is difficult for some of them.

The easier/base way would be to automate the testing/deployment of the released tags, so at least we can have information about if its broken or not, and anyone interested can fix it. This would prevent anything unnecessary like having a committee, and the devs would only need to check the commit and CI to keep the branch working.

1 Like

I imagine the only need to install older versions would be to migrate data while trying to upgrade instances to the newer versions. Is it possible to consider more number of master releases to support? as @lpm0073 said to ensure at least they continue to work. or maybe it would be easier to have one or two type of virtual machine images, with edx-platform installed, ready to use without any package installation needed which could be used to mount and to load&migrate data.

I love the idea of the community pulling together to help support the older releases they need. Who can put together a proof-of-concept of a continuous integration that installs the old releases?

1 Like

@nedbat, we at OpenCraft are looking into setting up periodic installs of arbitrary branches and I guess that can be extended to include previous named releases.

I will post an update once we have more details. FYI @xitij2000.