Hi all,

I'd like to open a discussion about the possibilities of formalizing a
release process for MatzRuby.

First, here are several points that contribute to the problems I see:

1. There are presently at least 4 highly viable alternative
implementations for Ruby. We agreed at a recent ruby-design meeting
that we would all follow MatzRuby's RUBY_VERSION and RUBY_PATCHLEVEL
to indicate to user code precisely what features and behavior that
code can expect of the language and libraries.
2. The RubySpec project includes "guards" (mechanisms to control the
execution of particular specs) for version_is/version_is_not and
ruby_bug that take a string like "1.8.6.114" to indicate version and
patchlevel. The guards make it possible to run the specs sanely across
many operating systems, versions, and implementations, but using the
guards also complicates the specs.
3. There are multiple currently-supported versions of MatzRuby (at
least 1.8.5.x, 1.8.6.x, 1.8.7.x, 1.9.x if I'm not mistaken).

The RubySpec project attempts to accommodate every single alternative
implementation and every supported version of MatzRuby at least from
1.8.6 onward. This is definitely a work in progress, but it has
accomplished a great deal toward the goal of ensuring that everyone
who writes Ruby code can do so with confidence that their code will
run correctly on any compatible version of the *Ruby language*, not
just on an implementation.

Recently, there has been an explosion of patchlevel commits in
MatzRuby. There have been over 200 since 4 June 2008, and there were
92 in a single day, on 15 June 2008. At least that's what I see with
these two commands:

svn log --limit 200 http://svn.ruby-lang.org/repos/ruby/tags
svn log --limit 200 http://svn.ruby-lang.org/repos/ruby/tags | grep
'15 Jun 2008' | wc -l

There are at least two significant problems that arise from the
combination of everything above.

First, whenever there are bugs in one of these released patchlevels,
the RubySpec sources must have ruby_bug and possibly version_is guards
added. The ruby_bug guard ensures that the spec for the correct
behavior will run on alternative implementations, but *not* run on the
MatzRuby version with the bug. This is done to prevent a bunch of
errors when running the RubySpecs on an already released version of
MatzRuby (since nothing can be done about the errors until a new
version or patchlevel). With so many patchlevels being released, the
number of these guards is increasing. While the guards are useful,
they complicate the specs and should ideally be avoided.

Second, since alternative implementations do not get any notice of
what features will be released, they are continually playing catch-up.
What this means for a user is that code that ran yesterday on JRuby,
for example, might break today on the released version of MatzRuby. If
we are all writing code for a particular implementation, this won't be
much of an issue. But one of the biggest goals of the RubySpec project
is to ensure that a user _does not have to worry about where their
code will run_.

So, I'd like to suggest that the community and the MatzRuby core
developers come to some agreement on a process for MatzRuby releases.
Here are several features I hope the process will include:

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.
2. A regular schedule of patchlevel releases on some reasonable
timetable (one month, two months?). For each of these scheduled
releases:
2.a. A wiki page on the new Redmine tracker that lists the features to
be rolled in from the particular version's development branch.
2.b. An opportunity for folks to run the specs against these proposed
changes to catch errors before the release is done.
2.c. Along with 2.b. this would give alternative implementations an
opportunity to plan to release the same fixes/features with the
corresponding RUBY_VERSION and RUBY_PATCHLEVEL synchronized to match
the MatzRuby releases at a time closer to when the MatzRuby releases
occur.
2.d. An opportunity for the community to then be aware of what is
planned to be released and comment on it so that we don't have
situations like what recently happened here (http://groups.google.com/
group/ruby-core-google/browse_thread/thread/1b116e4bbaeca3d2).

If the process is formalized a bit, I am sure there will be folks that
will help out with things needed at various stages. The RubySpec
project and the Rubinius project are working toward having a single
command that can be used to run the specs against all official
versions of MatzRuby based on Ryan Davis' multiruby tool. We hope to
make this process as simple and pain free as possible.

The Ruby community is presently growing in complex ways with the
appearance of multiple, useful alternative implementations of the Ruby
language. My hope (and I believe the hope of everyone who contributes
to or uses the RubySpec project) is to ensure people continue to find
the Ruby language great to use regardless of the implementation. Since
we are all following the "standard" implementation (MatzRuby), it
would help tremendously if we could, somehow, formalize (a bit) the
release process for MatzRuby.

Cheers,
Brian