On Wed, Apr 23, 2008 at 1:22 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote:
> 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? > I like 2 much better. Having potentially different binaries and/or tarballs between what's downloadable at Apache and Rubyforge is going to be a pain. Otherwise I agree with everything you said. Just a little technicality: as far as the ASF is concerned, we only vote on the source tarball. The binary is just a convenience offered to the users. Cheers, Matthieu > > Assaf >
