On Thu, Apr 13, 2017 at 1:35 PM Florian Bruhin <[email protected]> wrote:
> Hi, > > On Thu, Apr 13, 2017 at 06:25:22PM +0200, Ronny Pfannschmidt wrote: > > since quite a while now we keep a lot of code away from users by leaving > > it in the features branch, > > more recent detail https://github.com/pytest-dev/pytest/issues/2365 > > where even i didn't realize we had a fix since half a year. > > We probably just should do more feature releases then. > I agree we should have releases more often. Previously (at least from my POV) feature releases had one or more "themes" or major new features attached to it. 3.0 was about removing backward incompatibilities and adding a lot of new niceties (approx, doctest_namespace, etc). 3.1 in my head was about integrating pytest warnings and marks refactoring. Since we maintainers can only work on pytest on our spare time, a downside of this approach is that some feature might take a long time to land, which can hold back other small changes from reaching our users soon, like the issue Ronny mentioned. 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. One problem with this is that now our process requires some manual work which takes some to make a release. > and it has been a massive pain to keep merged with master over and over. > > Didn't seem like a "massive pain" to me so far. > IMHO I agree, I rarely see conflicts except for the CHANGELOG (which we plan to solve soon with the towncrier package). > As such i would like to stop using a features branch at all and return > > to having only master. > > And not have any bugfix releases? > 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. Cheers, Bruno.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
