Why not release the Gem as a release candidate version? Then, if the PMC vote approves it, release it again as a full release as a gem and on the Incubator site.
Cheers, Tal On Thu, Apr 24, 2008 at 8:54 AM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > On Wed, Apr 23, 2008 at 2:57 PM, Alexis Midon <[EMAIL PROTECTED]> wrote: > > > it's more about us as users than about PMC members (despite my respect ;). > > Solution #1 would bring confusion I think and might piss off many users. > > > > And what if the PMC vote is negative? One non-apache release 1.3 would be > > in > > the wild, available on Rubyforge while some updates would have to be done > > to > > prepare a new PMC vote. > > would you increment the version then? > > > Absolutely. > > We'll make a fix, then repeat the process again for the new version which > includes this fix. Whichever option we choose, we won't have two packages > with the same version number but different content. > > Assaf > > > > > > > > I'd rather consider rubyforge as simple file server, and stick to the > > apache > > process. > > > > > > > > > > On Wed, Apr 23, 2008 at 2:36 PM, Yoav Shapira <[EMAIL PROTECTED]> wrote: > > > > > On Wed, Apr 23, 2008 at 4:57 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > 1. Create all package files, changelog and signature. > > > > 2. Move those over to a public folder, where we can vote on them. > > > > 3. Following buildr-dev vote, upload these to RubyForge. > > > > 4. Following PMC vote, upload these to Apache. > > > > > > I really think we should have the PMC vote first. Otherwise you > > > unnecessarily get into gray area and might piss off some PMC members. > > > Why take the unnecessary risk? > > > > > > Yoav > > > > > > > > > -- > CTO, Intalio > http://www.intalio.com >
