Cool, that's good to know. The biggest admin issue I saw was tracking "what's suitable for a maintenance release", but certainly my impression is coloured by the big changes that went on since 9.0.1.
Paul On 7 March 2018 at 17:59, Donald Stufft <don...@stufft.io> wrote: > > 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!).
