[Rubygems-developers] RubyGems 1.3.0 Upcoming

Chad Woolley thewoolleyman at gmail.com
Fri Sep 12 19:54:20 EDT 2008

On Fri, Sep 12, 2008 at 3:20 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Aug 17, 2008, at 17:49 PM, Chad Woolley wrote:
>> Um, you mean 1.2.0, right?  That's what rubygems_version.rb says in
>> trunk, anyway.  Wait, I already have that installed!  Can you _please_
>> start bumping the version as soon as you release?  In other words,
>> after this release, bump to 1.4.0 in trunk, and bump to 1.4.1 again
>> right before release.  Multiple people have asked for this to make
>> their lives easier when integrating against trunk versions of
>> rubygems.  It's necessary if you need to put backward-compatibility
>> version-conditional logic when calling the RubyGems API.  If you
>> don't, I have to manually edit the version in whenever I integrate or
>> install from trunk.  It doesn't hurt anything for the public releases
>> not to end in zero.  It's the right thing to do.  NOT to do so sets a
>> bad example for other gems.
> rake install isn't enough?  Is there some other thing you could write with
> generate_rubygems_version (in Rakefile)?

This has nothing to do with rake install or the rakefile.

I'm saying to increment RubyGemsVersion in rubygems_version.rb in
trunk to be 1.4.0 as soon as you release 1.3.0.  Then, when you make
the 1.4 release, make it 1.4.1 (or, but 1.4.1 seems better).

This will allow people who write against the RubyGems API to use a
RubyGemsVersion check to make decisions about which API to go against
- the 1.3 API (released gem) or the 1.4 API (in trunk).

It makes sense.  As soon as you release 1.3, the trunk IS 1.4.  Unless
you decide it will be 2.0 (now or later), which is still fine, because
people should be doing >= in the API version checks anyway.

BTW, Koz just emailed me and this is what Rails is going to do for 2.2.

-- Chad

P.S. You'll still give a week warning before you release right?  I
still need to do a release to be compatible with 1.3...

More information about the Rubygems-developers mailing list