On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt < [email protected]> wrote:
> 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 think that sounds good for the feature releases. For bug fix releases I think a shorter time frame makes more sense, how about every 2 weeks? We could prepare the release PR Thursday and release on Friday. To organize who does the release, we could create a list of volunteers and just cycle into that list every two weeks... if someone won't be able to make a release on their turn due to personal reasons, he/she can ask in the list for someone else to step in. > 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. > Sure, count me in for this discussion. I was thinking of having a manual trigger, where one would make changes to a "regendoc-pytest" repository (like in my devpi-pytest experiment) and push it. This would trigger a regendoc run and PR, which could then be merged as usual. Running this job would then be part of the release process. It is still does require manual intervention, but is less error prone and does not require the person to have everything configured in their local workstation. Cheers, Bruno.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
