buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Release process [WAS Re: gradle]
Date Thu, 24 Apr 2008 15:39:00 GMT
On Thu, Apr 24, 2008 at 12:35 AM, Gilles Scokart <gscokart@gmail.com> wrote:

> On 23/04/2008, 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.
> >
> >  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.
> >
>
> It is true that the vote focus on source tarball (I think even some
> PMC even vote on an svn tag).
>

An svn tag isn't signed, I wouldn't consider that good practice.


>
> However the binary distribution has to
> follow some rules as well (licenses and notice file must be present
> also, for instance).  So I would submit it also with the vote.
>

Agreed. I was just pointing out that what *really* makes the release is the
source distro. See:

http://markmail.org/message/hgwdjaayxj5crzif

But yes, binary releases should also be submitted for the vote to make sure
they're kosher.

Matthieu


>
>
> --
> Gilles Scokart
>

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