[#688] mkmf.rb - add files to clean and distclean targets — Michal Rokos <michal@...>

Hi,

25 messages 2003/01/15
[#722] Re: [RFC] mkmf.rb - add files to clean and distclean targets — Mathieu Bouchard <matju@...> 2003/01/20

On Thu, 16 Jan 2003, Michal Rokos wrote:

[#740] Re: [RFC] mkmf.rb - add files to clean and distclean targets — matz@... (Yukihiro Matsumoto) 2003/01/21

Hi,

[#724] Symbols: More Functionality Wanted — Ryan Pavlik <rpav@...>

I've been discussing this for a bit on #ruby-lang on OPN (or freenode or

23 messages 2003/01/20
[#728] Re: Symbols: More Functionality Wanted — matz@... (Yukihiro Matsumoto) 2003/01/20

Hi,

[#743] Re: Symbols: More Functionality Wanted — "Pit Capitain" <pit@...> 2003/01/21

On 20 Jan 2003 at 15:49, Yukihiro Matsumoto wrote:

[#767] Re: Symbols: More Functionality Wanted — Mathieu Bouchard <matju@...> 2003/01/22

[#768] Re: Symbols: More Functionality Wanted — dblack@... 2003/01/22

Hi --

[#779] Re: Symbols: More Functionality Wanted — Gavin Sinclair <gsinclair@...> 2003/01/23

On Thursday, January 23, 2003, 6:28:04 AM, dblack wrote:

Adding Test::Unit to CVS

From: "Nathaniel Talbott" <nathaniel@...>
Date: 2003-01-22 05:31:06 UTC
List: ruby-core #759
Matz has already given me the go-ahead to add Test::Unit to CVS, but I
thought I'd make sure the strategy I'm planning to use is a good one
first.

Even though Test::Unit will be in the 1.7/1.8 distribution now, I still
have to maintain the distribution for 1.6, and I'm hacking pretty hard
on the source right now and don't want to introduce instability to 1.7
so close to the release of 1.8.0. Also, while I guess Rubicon may be
part of the distribution someday, it isn't today, which means there
isn't a good place for the Test::Unit tests to go (yet). Thus, I'm
planning on importing Test::Unit, using something like the following:

  cvs -d:pserver:ntalbott@cvs.ruby-lang.org:/src import -Ipre-install.rb
-m "Imported Test::Unit 0.1.6" ruby/lib testunit testunit_0-1-6

Now, I just discovered this command tonight, so maybe it isn't a good
way to do this. What I see as the advantage, though, is that then I can
just re-import every time I release a new version of Test::Unit, and the
main ruby distro won't be affected by bugs (yes, even with testing I
still introduce bugs <sigh>) that I may create in active development.

Now, some day I would expect to freeze development for the 1.6 line,
move the tests for Test::Unit in to Rubicon, and move the active
development work to the main Ruby distro, but I'd rather do that after
the 1.8.0 release and after Rubicon has moved in to the distribution,
too.

Is this a good plan? Is there a better strategy?


Nathaniel

<:((><
+ - -
| RoleModel Software, Inc.
| EQUIP VI 


In This Thread

Prev Next