> On Mar 7, 2018, at 12:39 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > At the moment,we don't have the infrastructure for doing bugfix > releases - and in this specific situation, pulling out the "ready to > go" parts of master to form an interim release isn't really practical, > given the resources we have. Once pip 10 is out of the door, I'd like > to investigate the possibility of having some sort of "maintenance > branch" setup, but we're so thin on the ground at the moment (with > Donald working on Warehouse and Xavier on leave of absence, it's > basically just Pradyun and I, and I'm not managing to actually work on > code much, just reviews and issue management) so I don't want to > overload what little resource we have with admin.
Doing a maintenance release is only a little bit harder than doing a regular release and I don’t think that maintenance branches fix it. If we wanted to we could create a maintenance branch *right now* by just doing ``git checkout -b release/9.0.2 9.0.1`` which would create a branch off of whatever was released as 9.0.1 that we can cherry-pick changes to. I don’t think pre-creating this branch at release time adds anything of value (and in fact I think it makes the situation generally worse). * If changes land to master first and then get cherry-picked into a maintenance branch, then it’s basically no different from what is available today. * If changes land to the maintenance branch first, and then get forward merged to `master`, then people will get confused and send backwards incompatible changes to the maintenance branch and need to be asked to rebase their branch onto master. * Having the branch exist at all will confuse people who don’t know where to send what branch where. * In the past, we’ve had bugs get fixed in a maintenance branch, then forget to merge that into master and “lose” the bug fix. Basically, I think sending changes to the maintenance branch first makes contributing to pip more confusing and more likely we lose things by accident and sending things to `master` branch then asking for a cherry-pick to a maintenance branch isn’t really much less effort than collecting issues at a hypothetical “we want to release 9.0.2” time, creating a branch then, and cherry-picking them all over at that time. In either case, a 9.0.2 release is hard because we vastly altered the structure of the code between 9.0.1 and `master`, so either solution doesn’t really help us get a hypothetical 9.0.2 released with whatever changes we think would be useful. When we don’t have big shifts like that, it’s pretty easy (I’ve done it more than once actually!).