Future Plans for Ruby 1.8 Series

This week Japanese rubyists were talking about the future of
ruby_1_8
branch. Triggered by the DoS vulnerability (refer
http://www.ruby-lang.org
) found in 1.8.5. There is a simple one-line
patch to fix this, but problem was that a ruby programmer
cannot simply
detect whether that patch was applied or not on their
system, as that
one-line patch doesn't change any version numbers.

Some rubyists asserted that they need new version of ruby
1.8 to detect
this. But that's not easy, because ruby_1_8 branch has been
far
developed from the point of 1.8.5 release. Releasing current
ruby_1_8 is
not a wise idea.

Debated on this, we now have these two choices:

(1) Ruby development goes into three-branch-model (like
branches in *BSD
world):
- CURRENT branch: trunk (currently ruby 1.9)
- STABLE branch: ruby_1_8 branch that exists now
- RELEASE branch: new branch to only adopt bug fixes

(2) ruby_1_8 branch to be frozen. No new development except
bug fixes
should be made on the branch.

Choice (2) was based on so-called "Denver Accord".
Meanwhile matz
expressed his opinion being (1).
Things are not fixed yet and (I think) should not until
debates made on
this ML. So I want you to tell us your opinion.

Where should ruby_1_8 go?

> Choice (2) was based on so-called "Denver
Accord". Meanwhile matz
> expressed his opinion being (1).
> Things are not fixed yet and (I think) should not until
debates made on
> this ML. So I want you to tell us your opinion.
Since 1.9.1 is planned for Christmas *2007*, choice (2)
would make *no* 
improvements for more than 1 year. It is very long time for
a feature freeze 
IMO.
-- 
Sylvain

On Thursday 09 November 2006 09:39, URABE Shyouhei wrote:
> Some rubyists asserted that they need new version of
ruby 1.8 to detect
> this. But that's not easy, because ruby_1_8 branch has
been far
> developed from the point of 1.8.5 release. Releasing
current ruby_1_8 is
> not a wise idea.

Is there no tag for 1.8.5 ? If there is, why not branch from
that, apply the 
patch, set the version number to 1.8.5.1, 1.8.5a, 1.8.6 or
whatever and tag 
that ?

This should be fairly simple, after all that's what VCS' are
for. Or am I 
missing something ? 

	Marc

-- 
Marc Haisenko
Comdasys AG

Rüdesheimer Straße 7
D-80686 München
Tel:   +49 (0)89 - 548 43 33 21
Fax:   +49 (0)89 - 548 43 33 29
e-mail: haisenkocomdasys.com
http://www.comdasys.com

Marc Haisenko wrote:
> Is there no tag for 1.8.5 ? If there is, why not branch
from that, apply the 
> patch, set the version number to 1.8.5.1, 1.8.5a, 1.8.6
or whatever and tag 
> that ?
>
> This should be fairly simple, after all that's what
VCS' are for. Or am I 
> missing something ? 

No.  That's plan (1).  But once you make a branch on CVS you
cannot
cancel that.  Creating a branch on CVS needs extreme cares
so I (and
other core team members) don't want to hurry forward.

Sylvain Joyeux wrote:
> Since 1.9.1 is planned for Christmas *2007*, choice (2)
would make *no* 
> improvements for more than 1 year. It is very long time
for a feature freeze 
> IMO.
>   

Matz, there is another one who believes 1.8 has not yet been
feature
frozen (for guys don't know, matz said "at least 1.8
core has already
been feature frozen")...

Plan (2) is to freeze not only the features of it, but also
its
implementation. Modifications are limited to fix bugs. We
need this kind
of "solid-rock" ruby anyway. Difference between
(1) and (2) are whether
we should create new branch for that purpose and leave
ruby_1_8 as it
is, or to turn existing ruby_1_8 branch into more solid
state.

> (1) Ruby development goes into three-branch-model (like
branches in  
> *BSD
> world):
> - CURRENT branch: trunk (currently ruby 1.9)
> - STABLE branch: ruby_1_8 branch that exists now
> - RELEASE branch: new branch to only adopt bug fixes
excuse me - why is it called "stable branch" if it
isn't stable enough
to be released anytime? I thought this was the purpose of
stable  
branches?

whatever. if there is a need for 1.8.6, just make that
branch, apply the
patch, release it, and mark it as "final" or
something. it's only  
computer
memory, after all ;)

afaik the cgi library is used heavily throughout Ruby web
applications,
including RoR. I don't know much about software relase
practicies,  
but it
sounds to me like a case of "fix it ASAP" - as
soon as possible!

while discussing the branch thing, this may be the right
time to think
about avoiding such things in the future. this type of bug
is quite
common. if I understood the code right, ANY malformed input
causes the
infinite loop. so, if anyone wrote a simple negative test or
two, it
might have been spotted immediately.

so I guess there never was a test case in the first place.
we should
change that. are there tests for cgi.rb yet, like set.rb
has? if not, I
can write some.

[murphy]

URABE Shyouhei wrote:
> (1) Ruby development goes into three-branch-model (like
branches in *BSD
> world):
> - CURRENT branch: trunk (currently ruby 1.9)
> - STABLE branch: ruby_1_8 branch that exists now
> - RELEASE branch: new branch to only adopt bug fixes
>   

You may not be familiar with it. STABLE is a *BSD technical
term and
does not mean a "stable source code". Refer these
documents:

http://www.freebsd.org/doc/en_US.IS
O8859-1/books/handbook/current-stable.html
http:
//www.netbsd.org/Releases/release-map.html

and useful ML debates:

http://lists.freebsd.org/pipermail/f
reebsd-stable/2006-September/028193.html

On Thu, Nov 09, 2006 at 05:39:42PM +0900, URABE Shyouhei
wrote:
> (1) Ruby development goes into three-branch-model (like
branches in *BSD
> world):
> - CURRENT branch: trunk (currently ruby 1.9)
> - STABLE branch: ruby_1_8 branch that exists now
> - RELEASE branch: new branch to only adopt bug fixes
> 
> Where should ruby_1_8 go?

I would like (1), since I have hopes of adding sandbox to
the ruby_1_8 line and
seeing it released previous to 1.9.1.  Are there plans to
actually release the STABLE branch?

_why

why the lucky stiff wrote:
> On Thu, Nov 09, 2006 at 05:39:42PM +0900, URABE
Shyouhei wrote:
>> (1) Ruby development goes into three-branch-model
(like branches in *BSD
>> world):
>> - CURRENT branch: trunk (currently ruby 1.9)
>> - STABLE branch: ruby_1_8 branch that exists now
>> - RELEASE branch: new branch to only adopt bug
fixes
>>
>> Where should ruby_1_8 go?
> 
> I would like (1), since I have hopes of adding sandbox
to the ruby_1_8 line and
> seeing it released previous to 1.9.1.  Are there plans
to actually release the STABLE branch?
> 
> _why
> 

I agree, because I have other hopes for additions to 1.8
(like the 
Kernel.ruby method to launch a new ruby script in an 
implementation-independent way).

What is the official word from Matz on whether there's a
feature or 
implementation freeze for 1.8? Isn't 1.9.1 a development
release anyway, 
not intended to become a wide release? If 1.8 series is
really done, and 
2.0 is not on any published timeline, what about
performance, security, 
stability fixes in the interim like this DoS fix or Michael
Selig's 
performance fixes or why's sandbox?

We're also interested from a JRuby standpoint...if it's
intended that 
people would move to 1.9.1 as "current" Ruby next
year, we would start 
considering how to make JRuby forward-compatible. If 1.9.1
is purely a 
development release (albeit a bigger, better, faster
development 
release) then people will be on the "frozen" 1.8
for much longer than a 
year.

-- 
Charles Oliver Nutter, JRuby Core Developer
Blogging on Ruby and Java  headius.blogspot.com
Help spec out Ruby today!  www.headius.com/rubyspec
headiusheadius.com -- charles.nuttersun.com

On Nov 9, 2006, at 12:39 AM, URABE Shyouhei wrote:

> Debated on this, we now have these two choices:
>
> (1) Ruby development goes into three-branch-model (like
branches in  
> *BSD
> world)
>
> (2) ruby_1_8 branch to be frozen. No new development
except bug fixes
> should be made on the branch.
>
> Where should ruby_1_8 go?

I like (1).  This allows new things to be added to 1_8
provided they  
don't break existing functionality.

-- 
Eric Hodel - drbrainsegment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotco
op.com