I agree with Donald on prematurely creating branches. A branch is only useful if it has a commit on it.
I approach maintenance slightly differently. I try to avoid leaving master unreleased at any point. Any changes to master get released near-immediately. The only time a branch is needed is when a back port of a bug fix is needed. This approach gives maintainers continuous stability and quick, uncomplicated feedback and simple rollback when something breaks unexpectedly. I think I’ve only once or twice had to release a bug fix for an older version of a library. In this environment, each contrib or batch of accepted contribs creates its own release, and the scope of that release is determined by semver and the impact of those changes. It’s minimally branchy, responsive, while giving users the greatest level of control over which functionality they opt into. Without this approach and a mechanical release process, there’s no way I could maintain 117 packages (thanks to warehouse, I now know that’s how many I own/maintain), which is why I recommend it. > On 7 Mar, 2018, at 15:13, Paul Moore <p.f.mo...@gmail.com> wrote: > > 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!).
