buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Victor Hugo Borja" <vic.bo...@gmail.com>
Subject Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Date Wed, 04 Jun 2008 23:59:02 GMT
Agree with Matthieu on version numbering, I think it should be 1.3.1.1 as
changes are mainly little bugs/dependency fixes.

Also .. given that we have an *unofficial* mirror on github, we could just
push the gemspec, so that people wanting to play with the version at HEAD
can do:

 sudo env JAVA_HOME=/opt/sun-jdk-1.5.0.13/ gem install vic-buildr -s
http://gems.github.com


On Wed, Jun 4, 2008 at 6:22 PM, Matthieu Riou <matthieu@offthelip.org>
wrote:

> On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <arkin@intalio.com> wrote:
>
> > On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <matthieu@offthelip.org>
> > wrote:
> > > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <arkin@intalio.com> 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 1.3.1.1 if possible though, to avoid holes in the official
> release
> numbering.
>
> 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.
>
> Cheers,
> Matthieu
>
>
> >
> > Assaf
> >
>



-- 
vic

Quaerendo invenietis.

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