The next Open edX release will be called Juniper. We want it to include the work currently ongoing to port our Python code to Python 3, since Python 2 reaches end-of-life in early 2020. Another major upgrade will be happening right after the Python 3 work: the move from Django 1.11 to Django 2.2, since Django 1.x goes out of support by April 2020.
The Python 3 work will likely not be stable for another month, which is why we haven’t started the Juniper work yet. The Django upgrade is more important, since Django does have an active stream of security fixes. Python 3 is needed before Django can be upgraded.
Our latest thought for Juniper is to wait until the Python 3 work is stabilized, then mark a Juniper alpha release. Our estimate now is that this would happen in early December. Then, once the Django 2.2 upgrade is done, we would have the official start of Juniper with a Juniper release candidate. That would likely happen in the March timeframe.
This means that Juniper happens significantly later than our ideal six-month schedule would dictate. But we wanted to get the much-needed upgrades in your hands as soon as they are ready.
Really glad to hear this work is close to stable! It’s been a massive effort, thanks to all who contributed!
Would it be possible to cut juniper.1 with Python 3, and do a juniper.2 for the Django 2.2 upgrade? Since Python 2.7’s EOL is Jan 1 2020, it would be awesome if we could have a named release, or at least a release candidate, on or about that date.
Python’s official EOL is Jan 1 2020, but we very rarely get security patches in Python that affect us. Also, the last Python 2.7 release will be 2.7.18 in April 2020. No, I cannot explain how the “EOL date” and the “last release date” can be three months apart. I tried asking the Python core devs for clarification, and they said both, “no big deal,” and “what does supported mean anyway?”
Once we make the Juniper master branches, we want to only put controlled fixes onto it as we tag juniper.1, juniper.2, etc. That prevents us from calling the Python 3 stable code juniper.1, and then the Django 2.2 code juniper.2. If we go back to master for juniper.2 to get the Django 2.2 work, then in what sense is it still Juniper?
The original plan was that Python 3 would be Juniper, and Django 2.2 would be Koa. But as the two releases seemed to be moving closer together, it didn’t make sense to do two named releases so close to each other. And we didn’t want to push Koa further out, because the Django security fixes are much more important than the Python fixes.
Maybe some part of my logic here is not lined up with how you look at the world? I’m happy to keep talking about possibilities.
Ah ok, that makes total sense. And at least we’d have a juniper alpha if for some reason the xenial packages start rotting after Python2.7 is done.
Do you know if any other base upgrades are planned for any of the other dependent services? e.g. MongoDB 3.4 EOL’s Jan 2020 too (cf discussion here), and we’re far behind on ElasticSearch too.
I might be misreading the tea leaves here, but I think we are still on Mongo 3.2, which is already out of support. And we are years behind on Elasticsearch.
I don’t think there are plans to change either version before Juniper.
I’ll be happy to see an early release of Juniper once the Python 3 update is done so that we have time to bang on it and iron out any missed edge cases. I also agree that it makes sense to wait for the Django upgrade before calling it an official release as there is likely to be a lot of code churn in that window.
In terms of other support windows, is there any plan to update the supported OS version to 18.04 from 16.04? It’s not strictly necessary as 16.04 still has 2 years left in the support window, just curious.
Hey Tobias, The DevOps team doesn’t currently have Bionic on our road map and given the complexities of adapting our devstack and packer builds to work we may opt to wait until the next LTS release before focusing on that work. We would be open to reviewing non-breaking configuration PRs though.
Looking at the chart of the support windows, Juniper was initially planned for October and Koa should be arriving by April 2020. Does it make sense to delay Juniper by 5 months so that both the python and django updates happen?
This is looking very similar to Ginkgo when a release that was supposed to last 6 Months was there for almost one year. Then migrating from ginkgo to hawthorn was more difficult, so many instances put if off and waited even longer. Missing the EOL dates completely for django 1.8 and for the GDPR. I think we are looking into the same scenario here. If Ned’s estimations of March are not met, then it could take even longer.
Maybe it makes more sense to release Juniper after the python3 work is done and release Koa after the django 2.2 work is done. That could make Juniper a short-lived release, but again if the March estimation is not met, then juniper lives for just as much and we don’t have a very long release in Ironwood.
Final thought, I could be overestimating the effort it took for sites to migrate out of ginkgo, I ran about 4~5 of those migrations and they where complicated. But others might think this was a breeze. Also I have almost no idea of how hard it is to prepare a release internally for edX and the mere thought of doing all that work for a short lived release could be laughable.
No you’re totally right, the ficus-to-ginkgo migrations were really complicated, because of the django-social debacle. This had nothing to do with open edx directly, but edX addressed it by creating intermediate release versions to make it possible for us to just step through the intermediate versions, instead of having to run a bunch of manual fixes. It would have been much harder without their efforts!
Migrating from ginkgo to hawthorn was a breeze by comparison, though… And hawthorn to ironwood was even easier, but they were quite close together. And you’re right, the more space that sits between the named releases, the more complex they can get. There’s more deprecations to deal with, more functionality changes that can make porting unmerged code harder.
Both the Python and Django upgrades sound like major changes to me. Unless you have very high code coverage in your automated testing, I recommend taking your time to get it all sorted before releasing. Or at least have several public betas before doing so. My strongest advice is to not let the 2020 conference influence your decision on when to release. Just my .02 coming from the perspective of a developer and a product manager.
