buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Release process [WAS Re: gradle]
Date Wed, 23 Apr 2008 20:57:10 GMT
On Wed, Apr 23, 2008 at 1:34 PM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> On Wed, Apr 23, 2008 at 1:22 PM, Assaf Arkin <arkin@intalio.com> 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.


I'm looking into this right now, but I don't think it will be a problem:

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.

Assaf


>
>
> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message