[Development] Proposal to adjust release candidate process

[Lars Knoll]

> On 28 Mar 2017, at 07:04, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
> On segunda-feira, 27 de março de 2017 21:21:41 PDT Jani Heikkinen wrote:
>>> Maybe every week is too aggressive, since few people will test every week
>>> and give feedback in time for the next release. We may find that every
>>> other week is better.
>> 
>> Yes, the goal is to have new beta n about week or two after previous one,
>> pretty much when we have important fixes in & when we have managed to
>> create content and verified that to be good enough. The main idea is that
>> we won't do new release from each successfully qt5.git integration by
>> default but still do several beta releases quite regularly (kind of need
>> basis).
> 
> My point is that weekly releases is too fast and will be confusing. People 
> will be testing beta N, and reporting next week what they've found, only to 
> run into people already testing beta N+1 and unable to reproduce the same 
> situations.
> 
> Maybe I'm wrong. The kernel does have weekly release candidates, so why not 
> us?

I’m all for releasing often. I don’t think it’ll be confusing to our users. Using the maintenance tool, they’ll get notifications, and updating from one beta to the next should be straightforward and easy. The only thing required is that we clearly identify the version they are using somewhere, and ask for that version in the bug report.

Updating often has the advantage that people will get bug fixes faster and especially can also verify them faster. 

Cheers,
Lars