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