[pytest-dev] on abolishing the feature branch concept

[Ronny Pfannschmidt]

For bugfix releases i would like to do them as soon as possible
(i.e. try to stay within one day of the merge)

that would also create more incentives for an better automation

-- Ronny

Am 25.01.2016 um 12:49 schrieb Florian Bruhin:
> * 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
> there.
>
>>> 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.
>
> Florian
>