On Wed, Jun 4, 2008 at 4:59 PM, Victor Hugo Borja <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: > >> On Wed, Jun 4, 2008 at 12:10 PM, Assaf Arkin <[EMAIL PROTECTED]> wrote: >> >> > On Wed, Jun 4, 2008 at 11:46 AM, Matthieu Riou <[EMAIL PROTECTED]> >> > wrote: >> > > On Tue, Jun 3, 2008 at 7:43 PM, Assaf Arkin <[EMAIL PROTECTED]> 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. >
