> 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 <[email protected]> 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 | [email protected] | 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
