Thanks marnie,
I am going to create a wiki page to capture the release process and the
requirments.
Once I do it, can u create a wiki page with the below mentioned points and
link it to the main page.
I will ping as soon as I create the page.

Regards,

Rajith

On 9/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:

Hi,

It'd be good to agree how we go about testing RCs. I've seen quite a few
cross-platform issues as I've used builds each week, mainly trivial but
still embarassing, so I'd like to see clarity around quality gates on
various envs.

First, we need to agree the set of platforms/envs we're supporting - I'll
start by offering the following for discussion:

- Linux 2.6+
- Windows XP 5+
- Solaris 8 (SunOS 5.8)+
- Cygwin ?

This list needs to be expanded/debated :-)

I guess we ought to plan an initial release early doors to encourage early
adpoter feedback ?

Regards,
Marnie






"Rajith Attapattu" <[EMAIL PROTECTED]>
12/09/2006 16:50
Please respond to qpid-dev

        To:     [email protected]
        cc:
        Subject:        Qpid Release Process


Hi Folks,

I think, this is a good time for us to discuss and agree on a release
mechanism that's agreeable to the Apache way.
As per my observations from projects like Axis2, Synapse, Tuscany,
Geronimo
...etc the release process is as follows.

We start with milestone releases (M1, M2 ...Mx) until we graduate from the
incubator.
Once graduated we can start doing a couple of 0.9x releases before we hit
the grand 1.0 release.

Here is the typical setup for any release.
Everything is decided based on a public voting on the list. (only binding
votes are counted)

Pre Release
-------------------
1. Create a wiki page and start capturing the feature/bug fix list for the
release
2. We can start a discussion thread and then come to a concensus on the
final list
3. These items should be tracked by jira or other means (jira is
preffered)
4. We can start a parallel thread on the release dates.

Release Process,
-------------------------
1. We should do a code freeze and put out a release candidate (ex RC1)
2. We should allow a minimum of one week for people to test/check out the
RC
3. If there are major issues maybe do a RC2 and follow the same process
4. If a majority is happy then we can do a code freeze and cut out a
release.

For incubator projects, I believe the incubator PMC has to vote on a
release.
Cliff, Paul can you please confirm??

For the first release I will volunteer to cordinate it.
Comments are appreciated.

Regards,
Rajith



This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market
prices, data and other information are not warranted as to completeness or
accuracy and are subject to change without notice. Any comments or
statements made herein do not necessarily reflect those of JPMorgan Chase &
Co., its subsidiaries and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure under
applicable law. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution, or use of the
information contained herein (including any reliance thereon) is STRICTLY
PROHIBITED. Although this transmission and any attachments are believed to
be free of any virus or other defect that might affect any computer system
into which it is received and opened, it is the responsibility of the
recipient to ensure that it is virus free and no responsibility is accepted
by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for
any loss or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and destroy the
material in its entirety, whether in electronic or hard copy format. Thank
you.


Reply via email to