[ruby-core:33612] Re: [Ruby 1.9-Feature#4085][Open] Refinements and nested methods

(2010/12/07 15:58), Charles Oliver Nutter wrote:
> On Mon, Dec 6, 2010 at 8:48 AM, Urabe Shyouhei <[e-mail]> wrote:
>> (2010/12/06 21:17), Charles Oliver Nutter wrote:
>>> This is what topic branches are for :)
>>
>> No.  That idea is not a SVN way.  A trunk in SVN is an actively developed edge
>> branch.  In contrast a master branch in Git is a merged collection of topic
>> branches, thus they are far less active than SVN trunk.  So in SVN,
>> developments goes on the trunk.
> 
> My opinion, from dealing with SVN-based projects in the past:
> 
> Experimental development should never go on SVN trunk. Trunk should
> only contain features that are intended to eventually get into a
> release. I'm not sure Refinements qualifies (yet) as an official path
> for Ruby, and so it should stay off trunk until that happens.
> 
> The alternative would be to let everyone doing any experiment
> whatsoever commit to trunk, and then have to sort out what gets into
> future releases and what does not. That does not make sense to me.

I think this is the whole point of this issue; what is a trunk.  At least
until now, trunk has been what I explained.  And you say it should not.

>>> I don't believe refinements
>>> should land on trunk, since it's not yet clear whether they should be
>>> included at all.
>>
>> I think it's all what you tell.  You just don't like it, do you?
> 
> I like Refinements, once they are "refined" to deal with the issues
> brought up in this thread :) I have no objection to them going to MRI
> trunk if they have reached the point where they're stable and
> acceptable enough to officially be part of Ruby's future.

I see.  Sorry for the unnecessary attack.

>>> Landing them now, making multiple additional commits
>>> to them, and propagating their changes throughout other
>>> subsystems...all will make it harder to roll back Refinements if it is
>>> decided they shouldn't get into standard Ruby.
>>
>> You say "now" ... Do you believe it gets easier to roll back as time goes?  I
>> don't think so.  If it's a matter of time I can agree with you but...
> 
> It gets harder to roll back as time goes on. Maintaining experimental
> features on a separate branch until they're blessed to become part of
> Ruby's future would ensure they don't have to be reverted much later.

So we have a consensus here.  The difference is I'm expecting a revert so I'd
see it happen sooner to reduce the risk, while you don't want it at all.