ruby-core

Hi folks,

Sorry, I'm joining this discussion a bit late, since I tried to
restrain myself and
not be negative, since the whole subject is sensitive.

Obviously, the MRI release process should be own and defined by ruby-core folks
themselves, but it is also clear that some processes are better for
other Ruby implementors,
and some are more problematic.

On Thu, Jun 19, 2008 at 5:16 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
> I think I was called :)
>
> The reasons why I committed so much was:
> 2) Sadly I was busy for a while so there were many bugs stacked, and at
> last I got time to touch them in 3 June.  This was my fault.  I should
> have done this more frequently, little by little.

I'm not really sure :) For me, the 1.8.6 line is a golden standard at
the moment,
and we try to follow its behavior when writing new RubySpec tests. So,
essentially,
MRI 1.8.6 is also a *REFERENCE* implementation. It is not good when
the reference implementation changes its behavior  from patchlevel to
patchlevel, hard to write specs, hard to understand what's the correct
behavior, lots of version guards in the specs, additional maintenance
to keep those version spec guards up-to-date.

And since the documentation for core/stdlib classes is not very
strict/precise, all we really
have is the MRI 1.8.6 behavior. Again, since the docs are not precise,
it is hard to distinguish between "bugfix" and "feature". Some
bugfixes are ending up changing behavior and introducing backward
incompatible changes.

Ideally (from my side of RubySpec contributor), the 1.8.6 line should
be really frozen and only highest-priority fixes should go there, like
security fixes.

>> 1. Security fixes should be highest priority. A patchlevel across
>> versions that incorporates security fixes should be released as soon
>> as possible. It would be great to have the issues communicated to key
>> folks across all alternative implementations, but that might not be
>> possible in every situation.

I fully agree with this one.

>> 2. A regular schedule of patchlevel releases on some reasonable
>> timetable (one month, two months?). For each of these scheduled
>> releases:
>>
>
> Maybe I've not said this?  Patchlevel "releases" (apart from those tags)
> are released every 3 months normally in Mar, Jun, Sep, Dec, except for
> security fixes of course.

Here's where I have a problem. The current patch levels are ordered, and you say
that the ones we see in the subversion repository tags, are not
"really released".

But what happens when a security issue found? Right, a new fix on top
of all previous patchlevels. And the security patch-level effectively
is a public release (which also gets LOTS of attention due to
sensitivity of the security problem), and that's where we have lots of
problems, since in the patchlevel changes we have: bugfixes (important
and critical and sometimes not important), some backward incompatible
changes (due to fixes, etc), some security fixes, some even minor
features.

The end result is that the patchlevel with security fix is way
unstable than needed.

Take a look at the comment here:
http://weblog.rubyonrails.com/2008/6/21/multiple-ruby-security-vulnerabilities

It clearly shows that the released security fix patchlevel is really
unstable/incompatible/non-useable.

Maybe that sounds radical, but how about using the patchlevel only for
critical/security fixes *ONLY*, no other non-critical changes at all?
And the regural fixes/features and even some controlled backward
incompatible changes should go to the next minor release?

Also, since MRI is de-facto reference implementation for Ruby
language, it would be really good to not have incompatible changes and
new features in the same version number. Why not use the proper
versioning mechanisms and release dot-dot releases when needed
instead?

Thanks,
  --Vladimir

Thread

Prev Next

In This Thread

Prev Next