buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: VOTE: 1.3.2 Gem release to resolve Hoe dependency problem
Date Thu, 05 Jun 2008 01:11:03 GMT
On Wed, Jun 4, 2008 at 4:59 PM, Victor Hugo Borja <vic.borja@gmail.com> wrote:
> 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

I'm not sure it creates a new Gem unless you update the .spec file.
Also, the .spec file doesn't include any dependencies specific to
MRI/JRuby (e.g. RJB), not sure how to work around that.

Also possible, publishing a script that will grab head/trunk and use
rake install to install it locally (but with remote dependencies).

Assaf


> 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
View raw message