[Releasing] Proposal to adjust release candidate process

Jani Heikkinen jani.heikkinen at qt.io
Wed Dec 21 09:19:16 CET 2016


> > What I really feel here is that these are symptoms of a more serious
> > issue, which is our commitment to time-based releases.
> >
> > Instead of entering the RC phase when the product is ready for it, we
> > forcibly push for it because of the approaching deadlines.
> >
> > This results in lack of proper testing before the RC (since there's no
> > real stabilization phase). Also, because in the RC phase only critical
> > bugfixes are accepted, we end up releasing a product with known
> > serious bugs (causing .0 releases to be frowned upon because full of bugs).
> 
>  [Kalinowski Maurice]
> I would object to that. The reason we are having so many delays for minor
> releases is that we are not taking the feature freeze seriously, push a huge
> amount of stuff still into it (with at least questionable significance) and pray
> that it'll work. As you mention, it never does, but neither does everyone
> accept the fact that each and every individual contributing raises the chance
> of causing regressions and further bugs at that stage.
> 
> The idea of having patch level releases more frequent is certainly welcomed,
> but then again the problems are the same, way too many changes for those
> causing a lot of effort for testing and verification.
> 
I totally agree with you. To be able to keep the schedules & quality we really need to start respect the feature freeze and decrease the amount of changes after it. By doing that we should eventually be able to dramatically shorten the release schedule as well (but of course first step is to be able to keep existing ones ;) )

So even someone wrote that we should be able to take more p2/p3 fixes in I think just opposite: We should minimize error fixes as well after FF and put focus to identify & fix real release blockers as early as possible and same time make sure we don't cause any new regression by fixing those nice-to-have's (even some of those might have really important in one's point of view but nice-to-have from release point of view). Those nice-to-haves can be fixed in dev...

> 
> While I can understand the background for this proposal, I still do not like the
> idea to call it Release Candidate, because right from the description it is not
> and hence distinguishes from any other software product doing releases
> including release candidates.
> 
> Maurice

I agree. IMHO RC means there isn't any known blockers left  and we will most probably release rc packages as final. And  I agree we could start officially releasing more betas (or one beta as now + few tech preview releases between beta and RC). But still we need to make sure we are fixing only blockers & so on limit the changes between different (sub) releases. 

br,
Jani



More information about the Releasing mailing list