C. Michael Pilato wrote on Thu, Jun 13, 2013 at 15:27:07 +0200:
> In the interest of serving our user base, we are proposing that each release
> live on the trunk for at most nine months. The first six months of this
> period are open to new features. In the first three months of the new
> feature period, large, destabilizing features will be accepted (under the
> provision that the feature itself is arguably “complete”, which seemingly
> implies that it was developed on a feature branch maintained with routine
The proposal also calls for such a release cycle to be used for the 1.9
release cycle, with the exception of possibly making the "Destabilizing
features permitted" window longer this one time (by way of transition
from the 1.8.x-and-earlier release cycle strategy), since we didn't know
in advnace we'd have such a window and don't have N features waiting to
be integrated / enabled (despite having just very recently cut the 1.8.x
branch).
So: about 4 months of a "destabilizing features" window, with the aim of RCs
in February and a release in March.
Daniel
> sync merges. In the second three months, we will still accept smaller new
> features. But at the end of the six months, the trunk is closed to new
> features and stabilization for the release begins. We will allow up to
> three months for stabilization on the trunk, cutting the release
> stabilization branch at the end of the period (or beforehand, if we agree
> that the codebase is ready for RC). The release branch is managed the same
> as it is today, with an RC at the earliest reasonable moment and the same
> soak requirements and such that we've always had.
Received on 2013-06-14 11:54:35 CEST