[Development] On the effectiveness of time based releases
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Mon Feb 24 13:17:58 CET 2014
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4048 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140224/30e01b15/attachment.bin>
More information about the Development
mailing list