Boost logo

Boost :

Subject: Re: [boost] [1.48.0] Proposed Release Schedule
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-07-13 10:15:55


Beman Dawes [bdawes_at_[hidden]] wrote:
>
> Given we are already in the middle of July, I feel strongly 1.48.0
> should target the first Monday in November, thus putting us back on
> our usual quarterly cycle. In our earlier schedule discussion, there
> was some interest in a three times a year release schedule, but the
> arguments were not convincing to me, so I really think we should keep
> to our quarterly schedule.
>
> The current formula for intermediate dates goes like this:
>
> * One week after prior release ships: branches/release opens for
> merging all stable changes, including bug fixes, and major upgrades to
> existing libraries. Breaking changes should be coordinated with
> libraries affected. New libraries may be added with permission of a
> release manager.
> * Seven weeks before release: branches/release closed for new
> libraries and breaking changes to existing libraries. Still open for
> bug fixes and other routine changes to all libraries.
> * Six weeks before release: QA checks on snapshot doc builds, inspect
> status, getting started guide, and install.
> * Four weeks before release: branches/release closed for major code
> changes. Still open for serious problem fixes and docs changes.
> * Three weeks before release: branches/release closed for all library
> changes except when specific permission given by release manager(s).
> * Two weeks before release: Beta target date. Further betas and/or
> release candidates as feedback dictates.

That's seven weeks for release, possibly longer based upon
extending the beta period, plus one week of release branch being
frozen following a release. 8 * 4 = 32. 52 - 32 = 20. 20 / 4 =
5 weeks between releases now.

> I propose that the Beta be scheduled for *Four* weeks before the
> release target date. All the other intermediate dates would thus be
> two weeks earlier.

Two weeks is tight, but adding two might be overkill. You don't
want to lose momentum or urgency by allowing too much time.

10 * 4 = 40. 52 - 40 = 12. 12 / 4 = 3 weeks between releases
with a four week beta period. I think that justifies releases
thrice per year. That also makes point releases less intrusive
on subsequent release cycles.

_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
Susquehanna International Group, LLP http://www.sig.com

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk