[ruby-core:59893] [ruby-trunk - misc #9215] Maintenance Policy for Future Releases (2.1.0 & beyond)

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.



-- 
http://bugs.ruby-lang.org/