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.


On 7 March 2018 at 17:59, Donald Stufft <> wrote:
> On Mar 7, 2018, at 12:39 PM, Paul Moore <> 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!).

Reply via email to