From: "Martin J. Dürst" <duerst@...>
Date: 2014-01-20T19:39:33+09:00
Subject: [ruby-core:59897] Re: [ruby-trunk - misc #9215] Maintenance Policy for Future Releases (2.1.0 & beyond)

Hello Zachary,

 From the comments from Yui, it looks like the policy should be split up 
into an internal (for Ruby commiters, and in particular those in charge 
of releases,...) and an external (for users) part.

Also, please note that because Ruby isn't a company, we have to be 
careful with commitments. It's clear that for Ruby users, the more and 
the more explicit commitments there are, the better. But on the other 
hand, everybody, in particular also people in charge of releases, are 
just volunteers. They may be able to use some of their company's time, 
but that may change. They may use some of their free time, but that may 
also change.

So with respect to release and support policy, it's very important to 
get the okay of the actual person in charge. Matz may be okay with some 
release or support policy, but if the actual person in charge isn't okay 
with it, that won't help.

Of course it's always possible that companies explicitly commit support 
for some version of Ruby (that has e.g. happened for Ruby 1.8.7), and I 
think it would be good if any related document such as a release policy 
would mention this possibility.

Regards,    Martin.

On 2014/01/20 15:43, naruse@airemix.jp wrote:
> Issue #9215 has been updated by Yui NARUSE.
>
>
>> We'd like to take a minute and discuss our plans for ruby-core supported maintenance periods of Ruby.
>
> "take a minute and discuss" is not useful for users. It should be simply "We release" or "decide" or something.
>
>> backports will be made to the `ruby_MAJOR_MINOR` branch
>
> this information is not for users.
>
>
>> The ruby-core team is responsible for a proper End-of-Life for each `MINOR` version of Ruby.
>>
>> Our current format is to assign a maintainer for each `MINOR` series of Ruby. It's important to note that this person is not obligated to commit for the entire 3 year suggested maintenance period.
>>
>> Our main goal to avoid sudden death.
>
> What do you want to say in these paragraph?
> If this is announce, the audience is users.
> They read this, "We want to avoid sudden death".
> "ah, ok... and what ruby-core will do?"
>
> The content is just a memorandum.
>
> See also rails' maintenance policy: http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/
> or you should see other policies.
>
>> Any decision made on Ruby development is based on the consensus of ruby-core as a team. The decision must be implicitly or explicitly approved by members of the maintenance policy team:
>
> This is not for users, just for you, zzak.
>
> ----------------------------------------
> misc #9215: Maintenance Policy for Future Releases (2.1.0&  beyond)
> https://bugs.ruby-lang.org/issues/9215#change-44446
>
> * Author: Terence Lee
> * Status: Feedback
> * Priority: Normal
> * Assignee: Zachary Scott
> * Category: doc
> * Target version: 2.1.0
> ----------------------------------------
> In order to support long lived applications better, people need information to make decisions. When someone chooses to use a particular programming language it���s important to know how long something is going to be supported.
>
> For future releases it���d be great if we could provide a formal end of life window upon release. This would allow companies to be able to make decisions on how long something will be supported. For instance, when Ruby 2.1.0 comes out this Christmas, giving an expectation that support will be stopped by 12/25/2015 gives an accurate picture of how much time must be allocated to upgrading, how urgent it will be, or if Ruby is even the right language for the project.
>
>
>