[pytest-dev] on abolishing the feature branch concept

Ronny Pfannschmidt opensource at ronnypfannschmidt.de
Mon Jan 25 06:06:42 EST 2016

I agree on the link article as well and like the model,
i propose a time-frame of either 3 or 4 months for the feature releases.

My personal preference is 3 months.

I already started with trying to automate regendoc,
my first attempt can be classified as failure.

I'd like to discuss a new approach at a later point in time.
the idea is to have a deploy handler, which will "deploy" a pull request
to maser/feature
whenever it notices differences after a regen run.

-- Ronny

Am 25.01.2016 um 11:34 schrieb Bruno Oliveira:
> On Mon, Jan 25, 2016 at 4:03 AM Florian Bruhin <me at the-compiler.org
> <mailto:me at the-compiler.org>> wrote:
>     I think the right route to go is to make releases easier (I think
>     Bruno is doing a great job on that!), and then maybe switch to
>     time-based releases rather than milestone-based releases like gitlab
>     does?
> Thanks! :)
> I read that link, thanks for that. It got me interested in trying that
> for pytest, seems like a good fit. As you noted, for that to work we
> would have to automate the process even further... for example, if we
> move the docs over to readthedocs, that would be one less step that
> needed to be done. Another point that should be automated is regendoc,
> which could follow a similar approach to what has been done in my
> devpi-pytest repository experiment, where we use Travis to run
> regendoc and open a PR against the pytest repository with the changes.
> All in all I'm really motivated to automate the release process as
> much as possible using the existing infrastructure we already have
> (Travis and AppVeyor).
> Cheers,
> Bruno.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20160125/4b5c3d5d/attachment.html>

More information about the pytest-dev mailing list