[pytest-dev] on abolishing the feature branch concept
me at the-compiler.org
Mon Jan 25 06:49:28 EST 2016
* Bruno Oliveira <nicoddemus at gmail.com> [2016-01-25 11:43:27 +0000]:
> On Mon, Jan 25, 2016 at 9:06 AM Ronny Pfannschmidt <
> opensource at ronnypfannschmidt.de> 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.
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
> > 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?
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.
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the pytest-dev