A bit of explanation for what goes next (Matthieu, correct me if I got anything wrong), and I'm working this form back to front.
We want to make 1.3 the first official Apache release of Build. That means making sure there are no outstanding issues, all test cases pass, documentation is up to date, and we don't have any licensing issues. The official release is held up to the Apache standard, and will be posted on the incubator Web site. To make that happen we need a formal vote o buildr-dev, followed by a formal vote in the PMC (Project Management Committee), that's 72 hours for each one. We're hoping to make it through on the first pass, so we're checking all the little details (licensing in particular) before starting. A lot of you would just want to do gem update, get the new release and start using it. These gem update releases are made through RubyForge, by me. They are not official Apache releases, there's no process for making these releases, we don't even have to vote on them. Regardless, I think we want to vote on both releases together. For a couple of reasons. First, putting anything up for vote means more people are looking into the code and testing it, so we get more stable releases. That's the benefit of voting on RubyForge releases. Second, life is easier if whichever package you download, they're both the same. So we're waiting to clear a couple of licensing issues, before starting the formal vote on buildr-dev. We'll need the actual gem, zip and tarball packages to vote on. If that gets approved (takes 72 hours), we have two options: 1. Immediately make a RubyForge release. Separately follow with PMC vote to make an official Apache release (another 72 hours). The Web site will be updated as soon as the RubyForge Gems are available. 2. Follow with a PMC vote, when that gets approved, make both RubyForge and Apache releases. I assume to most people it doesn't sound like much of a difference, but enough that I wanted to bring it up for discussion. If we follow the first process, we can make unofficial releases as well, this could come in handy if we need to do a quick release for a troubling bug fix. There's also the possibility that some releases will not get approved (usually licensing issues). In either case we can follow up with another official/unofficial release that fixes those issues. The second option guarantees that each RubyForge release is only for the convenience of using gem update, and is otherwise backed by an official Apache release. What do you all think about that? Assaf
