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 <[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.
