On 28 Mar 2008, at 05:02, Chad Woolley wrote: > Hi, > > 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.
I've had to do something similar for a number of projects where I have submitted patches which have not reached the release cycle yet. When the original authors are too busy, and we need the patch, the only sensible way I have found is to have some patch details, or just add another version number on to the end of the version set. Example: gem list --remote analogger ... analogger (0.5.0) gem list --local analogger ... analogger (0.5.0.1) Now this is 'ok' until the author replaces their versioning style or something similar. The generic problem though, is how to deploy 'local patches' or 'local versions'. I'm seriously considering doing this with any future releases of my own, having the last section of the version number always at 0 for official releases, so that users can specify their own patches with versions there, or use versions from committed patches straight from a repo. > Thanks, > -- Chad > _______________________________________________ > Rubygems-developers mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rubygems-developers _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
