> 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!).

Reply via email to