On Mon, Jan 25, 2016 at 9:49 AM Florian Bruhin <[email protected]> wrote:
> * Bruno Oliveira <[email protected]> [2016-01-25 11:43:27 +0000]: > > 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. > > I don't think it makes sense to do time-based *bugfix* releases. > GitLab does those as appropriate (i.e. whenever important enough fixes > pile up), and I think it makes more sense to keep the flexibility > there. > One benefit I see is that we would have a an answer for the common question "when will be the next bug fix release", which we always respond "as soon as we have some other get bugs fixed"... having a schedule for that also would allow people to prepare and plan themselves. > > > 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. > > I think that's what ronny proposed too, no? > I understood that Ronny's plan was to make regendoc run for every PR. I'm just commenting on what I had in mind to enrich the discussion with an alternate point of view. :) Doing a regendoc PR from Travis sounds like a good idea IMHO. First > maybe it should be more deterministic though, i.e. produce no changes > if there was nothing changing the output. > Certainly, I agree! Cheers, Bruno.
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
