[Rubygems-developers] Incrementing Gem::RubyGemsVersion on trunk?

Eric Hodel drbrain at segment7.net
Tue Apr 1 20:57:44 EDT 2008


On Mar 27, 2008, at 22:02 PM, Chad Woolley wrote:
> For my project, I run CI regression testing against several rubygems
> versions, which are embedded in specs fixtures dir:
> http://ci.thewoolleyweb.com/
>
> This is all dynamically specified through the cc.rb project name and a
> RUBYGEMS_VERSION env var:
> http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb
>
> I would also like to include a SVN external to automatically test
> against the latest rubygems trunk (which is nice because cc.rb trunk
> now detects svn external checkins).  However, this is difficult since
> the rubygems_version.rb on trunk is hardcoded to the version of the
> latest release, and for my approach to work, the dir name and rubygems
> version must match.
>
> Would you be open to either one of these two options?
>
> 1. 'preemptively' increment Gem::RubyGemsVersion after each release,
> to have a higher "tiny" component.  For example, the trunk now would
> be "1.0.1.1", or "1.0.1.99" or whatever...
>
> or
>
> 2. Allow an environment var to be passed, which if set would append
> the current trunk revision as the tiny component (and if not set,
> would not touch the version).  Something like this (but cleaned
> up/extracted):
>
> RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
> -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/ 
> r([0-9]*)/).first.first.to_s
> : "")
>
> Yeah, I know I can do this myself by rewriting the rubygems_version.rb
> file in the external before my CI build kicks off, but it would be
> nice to have it built in to RubyGems.

As a compromise of the solutions discussed in this thread, I set up  
`rake install` to overwrite rubygems_version.rb with data from  
`svnversion`.  Right now it doesn't know anything about installing  
RubyGems into other paths, but it could be easily taught to do the  
same as --prefix does.


More information about the Rubygems-developers mailing list