Dear Wiki user, You have subscribed to a wiki page or wiki category on "Qpid Wiki" for change notification.
The following page has been changed by cctrieloff: http://wiki.apache.org/qpid/QpidReleasePage/QpidReleaseProcess ------------------------------------------------------------------------------ MIGRATED to http://cwiki.apache.org/confluence/display/qpid/QpidReleaseProcess - = Qpid Release Process = - - 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. - 5. We should provide a 1.4 [http://retrotranslator.sourceforge.net/ retrotranslator] build of the client (only) with each release we make - - 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. -
