[pytest-dev] [proposal] abolishing the features branch

[Bruno Oliveira]

On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt <
opensource at ronnypfannschmidt.de> wrote:

>
> On 14.04.2017 14:17, Florian Bruhin wrote:
> > On Thu, Apr 13, 2017 at 05:51:34PM +0000, Bruno Oliveira wrote:
> >> What if we instead of considering features, we released a new minor
> version
> >> periodically, for say every month or two? We could adopt the same for
> bug
> >> fix releases, like each two weeks.
> > FWIW what GitLab[1] does is a monthly feature release, and patch
> > releases whenever needed. I don't think it's a good idea to have a fixed
> > release cycle for patches, but it sounds like it could work quite well
> > for feature releases indeed.
>

I'm curious, why do you think it is not a good idea to have a fixed or
semi-fixed release cycle for patches?


> https://github.com/pytest-dev/pytest/blob/master/HOWTORELEASE.rst is
> about 13 steps,
> most manual mundane and error-prone - it should be at most 1-2 steps
>

I agree, we should strive to improve that. The steps are not hard, but
still they are error prone (remember me sending the email for the pytest
3.0 release and writing "and this release contains a lot of bugs and new
features" instead of "... lot of bug **fixes** and..."). Heh.


> >> Having only a master branch, I think Ronny was proposing to then
> figuring
> >> out if it was a bug fix release or a minor release based on the
> CHANGELOG.
> > That means you either need to arbitarily hold back contributions, or you
> > lose the ability to do bugfix releases and need to do a feature release
> > (probably with new subtle bugs, looking at our track record) every time.
> if we make releasing inexpensive and reliable even a botched release an
> have a quick fix afterwards,
> i don't see a problem there, as long as we have processes in place that
> let stuff like "softening of xfail" to happen we'll have botched feature
> releases anyway,
> and IMHO that shouldn't stand in the way of removing unnecessary
> maintenance pain.
>
> what i want to remove is time eating and painful processes at releasing,
>

I appreciate Ronny bringing up this topic, a 3.1 release is long overdue.

We are discussing two things which have some interconnection:

1. Should we improve our release process, so that releasing a new version
is a 1 or 2 step process?
2. Keep or not a separate branch for ``features``.

I think we can all agree that 1) would be great and we want that.

Regarding 2), there's a few sub-points:
2.1) Periodically have to merge master into ``features``; Ronny believes
this is a pain, IMHO it's not a big deal;
2.2) How often should we release bug fixes and feature releases? This is
impacted directly by question 1: the easier to make a new release, more
often we will do it (just pushing a tag every Thursday for a new bug fix
release for example).

I definitely agree that we should have more frequent feature releases than
what we have now; I was under the mentality that we wanted all feature
releases with 2 or 3 major themes and new additions, but given that we
can't really guarantee time to implement these new features it might make
more sense to just make new feature releases with just minor improvements
and changes.

Having said that, I think it is still worthwhile to keep the features
branch so we can issue bug-fixes quickly and periodically. But for that to
work, we need to improve the release process so that it takes one or two
steps at most; we have excellent CI at our service to help us accomplish
that.

I really would like for us to reach a consensus here. :)

Cheers,
Bruno.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170419/f8332899/attachment.html>