On 7 March 2018 at 21:25, Jason R. Coombs <jar...@jaraco.com> wrote:
> I agree with Donald on prematurely creating branches. A branch is only useful
> if it has a commit on it.
+1 I wasn't particularly thinking of actual git branches, more whether
we needed somewhere for "things that can be released now" vs "things
that need some time to complete". On reflection, I prefer an approach
where master should be ready to release at all times. Release blocker
bugs should be extremely rare (as they imply we put something on
master that makes pip basically unusable).
> 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.
I'm quite happy to consider the idea that we increase the pace of
releases and work on the basis of master having to always be in a
releasable state. Prior to the pip 10 complications, that's
essentially how we always worked. Lesson learned, I think :-)
> 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.
I'd certainly be interested in exploring this option. Once pip 10 is
out of the door, I'll look into this in more detail. I'll probably be
back with some more questions :-)