qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: Release Schedule
Date Thu, 12 Feb 2009 13:32:46 GMT
Hi Martin,

Thanks for volunteering and for proposing a schedule.

This sounds like a good plan for me, and would fit well with the M5 Java
Scope, at least the items we have defined in scope thus far.


On Wed, Feb 11, 2009 at 1:41 PM, Martin Ritchie <ritchiem@apache.org> wrote:

> Hi as Release Manager for our next release I'd like to suggest the
> following time line for this release.
> Development--->|<--- Bug Fix, Feature Freeze --->|<--- Branch ---> |
> Release
> The dates for each phase would be as follows:
> End of Development : 2009-03-02
> End of Feature Freeze : 2009-03-16
> Release : 2009-03-27
> These dates have been picked as we had previously shown an interest in
> getting a release out in March. To achieve this we are following a
> time boxed release schedule as we have done in the past.
> In our previous release the notion of a 'Feature Freeze' was unclear
> so for would define it for this release as:
>  - Bug fix commits only
> In response to the feedback from M4:
> http://cwiki.apache.org/confluence/display/qpid/M4+Release+Process+Notes
> I will address all of the points in a later email but some of the
> points can be addressed here.
> Previously we also had concerns (Note 4) about the length of time that
> trunk would be in a bug fixing phase. To address this I propose that
> we time box the phase to two weeks. If we have not completed bug
> fixing in that time a branch will be made. This will allow new feature
> development to continue on trunk whilst the, hopefully few, bugs are
> ironed out in the release branch. Of course if we do get to a stable
> release point before the end of the two week window a branch will be
> taken at that point, lifting the trunk freeze early. I believe this
> approach of branch and tag should also be adopted for future releases
> and was the process ultimately used by M4; this would address Note 10.
> On entering the bug fix phase all new features currently assigned to
> the release and not committed will be de-scoped, at that point a
> performing a JIRA review to prioritise blocking issues should help
> address Notes 1, 5 and 7. At this point only new bug fix JIRAs should
> be added to the release.
> An alpha will be created at the start of the bug fix phase for testing
> and so we can verify the package contents for licensing (Note 9) and
> functionality. A beta may also be issued as we near the end of bug
> fixing to allow package providers to verify that everything is still
> in good order.
> When we have resolved the blocking issues an RC will be created for
> final testing and ultimately voting.
> Regards
> Martin
> --
> Martin Ritchie
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message