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.

Regards,
Marnie

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
>
>

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