[Development] On the effectiveness of time based releases

[Robert Knight]

> Unfortunately, it looks to me that time based releases seem to
> encourage developers to try to rush to get their feature in.

The theory is that developers shouldn't panic about missing a
particular release because the next release date is predictable
and developers can catch the next train if necessary. If that's not
happening as intended, perhaps this is a good time to ask why.

On 24 February 2014 12:17, Giuseppe D'Angelo <giuseppe.dangelo at kdab.com> wrote:
> Hello,
>
> right next to the discussion about the branching model, I'd like to
> propose a discussion about the time based releases. In particular,
> both for 5.2 and for 5.3 the model has IMO failed, in that features
> that were considered "too good to be missing" were rushed in at the
> last second (or even merged in stable after the actual dev->stable
> merge did happen).
>
> Some of those features then either caused regressions (... ok,
> that's what betas are for, although it may also be a symptom of poor
> testing in order to get the feature in), or are highly debatable
> from an API / technical point of view (which is even worse, because
> we can't change APIs or behaviour once we release). (*)
>
> The current branch guidelines [1] say
>
>> dev: unfrozen branch, containing alpha-quality code
>> that is ready to go into beta testing at any time
>
> "Alpha quality code" still means that the code respects *ALL* of the
> following:
>
> *   for any "major" feature, and any metric of "major" (wide
>     audience, complex implementation, deep impact for users, ...),
>     the feature got through a round of public debate on the ML
>     (still, lazy consensus applies);
>
> *   has gone through a round of public API review (possibly outside
>     of gerrit. on gerrit it would do if it also comes with
>     exhaustive example code);
>
> *   is carefully documented;
>
> *   it has proper autotests (if appliable);
>
> *   strictly follows Qt coding guidelines;
>
> *   compiles on all reference platforms;
>
> *   works on all reference platforms;
>
> *   possibly, it has been tested by third parties who got involved
>     in the above processes.
>
> Code missing ANY of these does not belong to dev. It belongs to a
> working branch (under CI) which can be rebased on dev and merged
> when the code is ready. It certainly not belongs to stable.
>
> Unfortunately, it looks to me that time based releases seem to
> encourage developers to try to rush to get their feature in. This
> may be an indication that we'd like to move to feature-based
> releases. Which I have nothing against, except that we then need to
> discuss, agree and change our own rules.
>
> [1] http://qt-project.org/wiki/Branch-Guidelines
>
> (*) I'll deliberaly keep the technical discussion outside of this
> thread and start new threads to address the issues. This is about
> the policy.
>
> --
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer
> KDAB (UK) Ltd., a KDAB Group company
> Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>