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 <[email protected] > <mailto:[email protected]>> 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.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
