[ruby-core:17421] Re: A plea for a release process

	I have to agree with Charles. We have no plans to upgrade to  
ruby1.8.7 as it is broken. Ruby1.8.6p111/p114 is what I and most  
others consider to be ruby. Any new features in the 1.8.* branch  
should have only gone in 1.9 or been justified and tested by the  
community before being released and reeking havok on the ruby community.

	Ruby has seen far too much adoption for the release management to be  
so completely broken. We have the rails test suite and the ruby specs  
that can help manage releases and let us know that things have not  
broken. but for some reason releases are still made without running  
either of these spec suites.

	How can we the ruby community get the point across to ruby-core that  
the current process is completely broken and needs to be revamped from  
the bottom up?

	Rubinius is currently targeting 1.8.6p114 as well since it seems to  
be the last sane release of the ruby 1.8 line.

Thanks-
-Ezra


On Jun 27, 2008, at 7:01 PM, Charles Oliver Nutter wrote:

> I'll sum up my feelings in as few words as possible:
>
> - JRuby has not started to move away from 1.8.6p114 compatibility,  
> because we keep hearing reports about app breakage in later  
> patchlevels and in 1.8.7. This is extremely worrisome.
> - I think we need to take a step back and examine all behavioral  
> changes post 1.8.6p114 and justify them individually. If behavioral  
> changes can't be justified and are backward-incompatible, they must  
> be reverted.
>
> We have too many people using Ruby now to break things in  
> patchlevels and minor releases, and JRuby for one will not leave  
> users with an option of not upgrading or upgrading and breaking  
> their apps.
>
> Brian Ford wrote:
>> 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
>
>

- Ezra Zygmuntowicz
-- Founder & Software Architect
-- [e-mail]
-- EngineYard.com