[pytest-dev] on abolishing the feature branch concept
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
whenever it notices differences after a regen run.
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
> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pytest-dev