buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles Scokart" <gscok...@gmail.com>
Subject Re: Release process [WAS Re: gradle]
Date Thu, 24 Apr 2008 07:35:34 GMT
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).  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.


-- 
Gilles Scokart

Mime
View raw message