buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <>
Subject Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Date Wed, 04 Jun 2008 23:22:42 GMT
On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <> wrote:

> On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <>
> wrote:
> > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <> wrote:
> >
> >> Looks like we've got another dependency problem.
> >>
> >> There are two workarounds, install from source or remove the newer
> >> hoe/rubyforge dependency, both of which will have to be done after
> >> installing/upgrading 1.3.1, and every time you run gem update, which
> >> will restore the newer dependencies.
> >>
> >> I'm proposing we push a new Gem to RubyForge without making an
> >> official release, there will not be a corresponding Apache
> >> distribution, and it will not contain any other changes from trunk
> >> besides new version number and fixed Gem dependencies.
> >>
> >
> > Why?
> Because minimizing it to just a majority vote on buildr-dev, and then
> packaging a Gem and uploading to RubyForge and is something we can get
> over and done with today.
> Going through the full process, not until mid/late next week.

So given that this is an unofficial release that you decide to publish for
people's convenience, without my PMC hat on and only as a community member,
I'll vote +1 because this little packaging problem needs fixing. I'd rather
name this if possible though, to avoid holes in the official release

Now with my PMC hat on, I'd *really* like the documentation to make very
clear that what's published on Rubyforge isn't in any way endorsed by Apache
and is only community driven. We should have a disclaimer explaining why we
do this (emergency Rubygems conf related releases) and how people can
install making sure you only get the Apache releases.

I'd also suggest that if another unofficial release is needed, we clearly
flag the vote e-mail with unofficial to avoid readers' confusion.


> Assaf

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