IMHO 3 or 4 days is not enough for the community to give feedback on a RC, especially when it includes a week-end. The first release candidate at least should let one week to the community to try out the RC and raise issues if any. It's unlikely the first RC will be promoted to a release anyway, so letting more time is just to collect more issues and raise the probability for the second RC to be promoted.
Otherwise the schedule looks good. Xavier On 6/7/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
This is the proposal for our end game to a final release of Wicket 1.3.0 - build 1.3.0-beta 2 this weekend, release next week - after the 20th start work on release candidates: These will not be official releases, because I want to move quickly on these builds. So at least once every week we (I?) will publish a new release on people.apache.org. We will hold a vote on whether the released packages will be the final version, or a new release is necessary. Schedule: 6/09 release beta 2 6/15 make beta 2 available for general public, if PPMC and IPMC don't object 6/20 board@ meeting, graduate? 6/23 build rc1 6/26 vote: make rc1 final, or build a new one 6/30 build rc2 7/03 vote: make rc2 final, or build a new one 7/07 build rc3 7/10 vote: make rc3 final, or build a new one 7/14 give up Any one have other/better/alternative ideas? Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
-- Xavier Hanin - Independent Java Consultant Manage your dependencies with Ivy! http://incubator.apache.org/ivy/
