[pytest-dev] 2.8.0 release plan? 2.7.2?

[Floris Bruynooghe]

We could also follow how zeromq does things and simply not have branches in
the main repos, using forks instead for maintenance releases.  It does not
help with the fact that we'd be back in charge of cherry picking fixes for
bugfix releases though.

But I honestly don't mind too much, happy to leave the branch workflow to
people more experienced with git then me.

Floris
On 19 Jun 2015 09:28, "Florian Bruhin" <me at the-compiler.org> wrote:

> * holger krekel <holger at merlinux.eu> [2015-06-18 05:47:26 +0000]:
> > Would it make sense to consider "master" to become the new "bug fix
> branch"
> > and have a "pytest-2.9" then where we collect new features? This way
> > the default is to do bugfixes which might be easier for newcomers to
> > the project.
>
> Another possibility (GitLab flow[1]) would be to make all commits to
> master, and then cherry-pick bugfixes to a, say, pytest-2.7 branch.
>
> That's what I use for my project, and I'm quite happy with it. It
> means a bit more work for maintainers (as they have to cherry-pick
> things), but it takes the "burden" of deciding/knowing which branch to
> use from the contributors.
>
> [1] https://about.gitlab.com/2014/09/29/gitlab-flow/
>
> Florian
>
> --
> http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
>    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
>          I love long mails! | http://email.is-not-s.ms/
>
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20150622/f9fe171a/attachment.html>