Hi, +1 for making releases easier.
Just a thought on the side: mid to long term we might even be able to synchronize workflows between projects and do something like jazzband ( https://jazzband.co/) for pytest/tox/devpi and plugins that are maintained by the community. Cheers, Oliver On Wed, 19 Apr 2017 at 13:42 Bruno Oliveira <[email protected]> wrote: > On Mon, Apr 17, 2017 at 3:49 PM Ronny Pfannschmidt < > [email protected]> 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. > _______________________________________________ > pytest-dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/pytest-dev >
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
