Removing edx specific packages | | |
Spreading out the release risk | | We have knowledge of what will be EOL, but we could be planning more with this knowledge Some upgrades end up being dragged out, but then a deadline is what makes them speed up. There are often many upgrades in flight at the same time. JR recommends focusing on one effort at a time Py3.11 has been moving quickly in the past few months, with a lot of focus and intentionality, which is good We made tickets in all the relevant repos it’s good to know all the outstanding upgrades, but it’s also good to know which are higher priority. So, balance between parallelization and focus. having one ticket with one assignee has helped the py311 upgrade move. open to feedback on improvements on this process
Leaders in upgrades It helps to have someone leading an upgrade, coordinating the tickets across repos and rallying maintainers (eg Feanil 3.11, Felipe 3.12?!?) Also helpful for this person to collect info – breaking changes and the like thoughts on electing leads for upgrades?
Feanil is writing down some process docs for upgrades. Would be good to get instructions for upgrades all types of repos. Just a lot of little steps to remember – udpdate the version, tag a release, update the constraint, yada yada What’s one we could start early? Repo tooling modernization and consistency
|