[Rubygems-developers] Trunk version of rubygems should always be > released version

Ryan Davis ryand-ruby at zenspider.com
Wed Jun 24 23:06:24 EDT 2009

On Jun 24, 2009, at 19:07 , Chad Woolley wrote:

> However, if you keep the trunk version the same as the released
> version, it is a lot more effort to fake a different version than
> actually exists in the code - instead of just a simple comparison of
> the actual version using Gem::Version::Requirement#satisfied_by?

I'm gonna wade in on this thread ONE time only...

This is a false dilemma. You're insisting on using the version to  
distinguish trunk-run-from-svn vs released versions. But you (should)  
already know you're running from trunk vs running on released  
versions. Not only that, you're also running on every commit made to  
trunk. Don't you want to distinguish them from each other?. If you do,  
use svn to your advantage and tack it onto the version:

   "#{current_version_or_trunk_or_whatever}.r#{`svnversion .`}"

Eric pointed out that multiruby uses the install directory names to  
distinguish the versions:

> % ls ~/.multiruby/install/
> 1.8.6-p287	1.8.6-p368	1.8.7-p160	1.8.7-p72	1.9.1-p129

and that is the only thing it uses to report versions on runs. It  
doesn't have to be fancier than that. If I were to extend multiruby to  
run on multiple commits on trunk, I'd use the snippet above to report  
the exact commit.

Just because something makes sense in your development model doesn't  
mean it makes sense in ours. Right before a release, we look at the  
changelog from the last release to the head of trunk and determine  
what sort of version bump it needs (major/minor/bug). Doing more than  
that is not a good use of our time. Changing the version TWICE for  
every release makes as much sense as knees on a fish to us.

Finally, I meant what I said about one time only. I'm not going to  
respond to anything else on this thread. I've been watching it go by  
and the only word that comes to mind consistently is "mentarbation".  
Please. Drop it. Let's get on to more useful things.

More information about the Rubygems-developers mailing list