https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112013-12-10T05:16:08ZRuby Issue Tracking SystemRuby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=435562013-12-10T05:16:08Zzzak (zzak _)
<ul><li><strong>Category</strong> changed from <i>Project</i> to <i>doc</i></li><li><strong>Status</strong> changed from <i>Open</i> to <i>Assigned</i></li><li><strong>Assignee</strong> set to <i>zzak (zzak _)</i></li></ul><p>We have decided the following:</p>
<ul>
<li>MINOR level versions of Ruby have a "best effort" goal of at least 6 months and at best 3 years.</li>
<li>TEENY versions will be released approx. every 2-3 months</li>
<li>Branch maintainers are not obligated to commit 3 years maintenance</li>
<li>ruby-core as a team is responsible for a proper EOL for each MINOR version</li>
</ul>
<p>Our main goal is to avoid a sudden death</p>
<p>Assigning this ticket to myself in order to document the approved maintenance plan.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=442452014-01-13T04:14:59Zzzak (zzak _)
<ul></ul><p>I've written a draft of the <a href="https://github.com/zzak/www.ruby-lang.org/blob/future_release_policy/en/news/_posts/2014-01-13-approved-maintenance-policy.md" class="external">future maintenance policy</a>.</p>
<p>Please check it.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=442462014-01-13T04:20:38Zzzak (zzak _)
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Feedback</i></li></ul><p>I will give some time for feedback before closing this and opening a Pull Request on the upstream <a href="http://www.ruby-lang.org" class="external">www.ruby-lang.org</a> repository.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444042014-01-18T07:48:37Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><ul>
<li>Who is "we"?</li>
<li>It doesn't define what is "support"</li>
<li>"at least 6 months and at best 3 years" is the conclusion. it is at least X years or after two newer release, in my understanding</li>
<li>"TEENY versions will be released approx. every 2-3 months" should be 2-4 months. it also needs how ruby-core treat older teeny (if this is announce)</li>
<li>How to finish a release maintenance is essential information. an announce must have it.</li>
</ul>
<p>Anyway decisions on Ruby development is based on consensus building.<br>
A decision must be implicitly/explicitly approved by persons concerned in the decision.<br>
Persons concerned in the maintenance policy is naruse, usa, nagachika.<br>
At least you get explicit approval by them. (idealy a comment on redmine or reply to ML)<br>
A meeting is not enough. It means only sharing information)</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444432014-01-20T04:44:14Zzzak (zzak _)
<ul></ul><p><a class="user active user-mention" href="https://bugs.ruby-lang.org/users/5">@naruse (Yui NARUSE)</a> thank you for the review!</p>
<p>I've made the changes you listed above in the following pull request: <a href="https://github.com/ruby/www.ruby-lang.org/pull/602" class="external">https://github.com/ruby/www.ruby-lang.org/pull/602</a></p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444462014-01-20T06:43:04Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><blockquote>
<p>We'd like to take a minute and discuss our plans for ruby-core supported maintenance periods of Ruby.</p>
</blockquote>
<p>"take a minute and discuss" is not useful for users. It should be simply "We release" or "decide" or something.</p>
<blockquote>
<p>backports will be made to the <code>ruby_MAJOR_MINOR</code> branch</p>
</blockquote>
<p>this information is not for users.</p>
<blockquote>
<p>The ruby-core team is responsible for a proper End-of-Life for each <code>MINOR</code> version of Ruby.</p>
<p>Our current format is to assign a maintainer for each <code>MINOR</code> series of Ruby. It's important to note that this person is not obligated to commit for the entire 3 year suggested maintenance period.</p>
<p>Our main goal to avoid sudden death.</p>
</blockquote>
<p>What do you want to say in these paragraph?<br>
If this is announce, the audience is users.<br>
They read this, "We want to avoid sudden death".<br>
"ah, ok... and what ruby-core will do?"</p>
<p>The content is just a memorandum.</p>
<p>See also rails' maintenance policy: <a href="http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/" class="external">http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/</a><br>
or you should see other policies.</p>
<blockquote>
<p>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:</p>
</blockquote>
<p>This is not for users, just for you, zzak.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444492014-01-20T14:23:18Zduerst (Martin Dürst)duerst@it.aoyama.ac.jp
<ul></ul><p>Hello Zachary,</p>
<p>From the comments from Yui, it looks like the policy should be split up<br>
into an internal (for Ruby commiters, and in particular those in charge<br>
of releases,...) and an external (for users) part.</p>
<p>Also, please note that because Ruby isn't a company, we have to be<br>
careful with commitments. It's clear that for Ruby users, the more and<br>
the more explicit commitments there are, the better. But on the other<br>
hand, everybody, in particular also people in charge of releases, are<br>
just volunteers. They may be able to use some of their company's time,<br>
but that may change. They may use some of their free time, but that may<br>
also change.</p>
<p>So with respect to release and support policy, it's very important to<br>
get the okay of the actual person in charge. Matz may be okay with some<br>
release or support policy, but if the actual person in charge isn't okay<br>
with it, that won't help.</p>
<p>Of course it's always possible that companies explicitly commit support<br>
for some version of Ruby (that has e.g. happened for Ruby 1.8.7), and I<br>
think it would be good if any related document such as a release policy<br>
would mention this possibility.</p>
<p>Regards, Martin.</p>
<p>On 2014/01/20 15:43, <a href="mailto:naruse@airemix.jp" class="email">naruse@airemix.jp</a> wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Maintenance Policy for Future Releases (2.1.0 & beyond) (Closed)" href="https://bugs.ruby-lang.org/issues/9215">#9215</a> has been updated by Yui NARUSE.</p>
<blockquote>
<p>We'd like to take a minute and discuss our plans for ruby-core supported maintenance periods of Ruby.</p>
</blockquote>
<p>"take a minute and discuss" is not useful for users. It should be simply "We release" or "decide" or something.</p>
<blockquote>
<p>backports will be made to the <code>ruby_MAJOR_MINOR</code> branch</p>
</blockquote>
<p>this information is not for users.</p>
<blockquote>
<p>The ruby-core team is responsible for a proper End-of-Life for each <code>MINOR</code> version of Ruby.</p>
<p>Our current format is to assign a maintainer for each <code>MINOR</code> series of Ruby. It's important to note that this person is not obligated to commit for the entire 3 year suggested maintenance period.</p>
<p>Our main goal to avoid sudden death.</p>
</blockquote>
<p>What do you want to say in these paragraph?<br>
If this is announce, the audience is users.<br>
They read this, "We want to avoid sudden death".<br>
"ah, ok... and what ruby-core will do?"</p>
<p>The content is just a memorandum.</p>
<p>See also rails' maintenance policy: <a href="http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/" class="external">http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/</a><br>
or you should see other policies.</p>
<blockquote>
<p>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:</p>
</blockquote>
<p>This is not for users, just for you, zzak.</p>
<hr>
<p>misc <a class="issue tracker-5 status-5 priority-4 priority-default closed" title="Misc: Maintenance Policy for Future Releases (2.1.0 & beyond) (Closed)" href="https://bugs.ruby-lang.org/issues/9215">#9215</a>: Maintenance Policy for Future Releases (2.1.0& beyond)<br>
<a href="https://bugs.ruby-lang.org/issues/9215#change-44446" class="external">https://bugs.ruby-lang.org/issues/9215#change-44446</a></p>
<ul>
<li>Author: Terence Lee</li>
<li>Status: Feedback</li>
<li>Priority: Normal</li>
<li>Assignee: Zachary Scott</li>
<li>Category: doc</li>
<li>Target version: 2.1.0</li>
</ul>
<hr>
<p>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.</p>
<p>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.</p>
</blockquote> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444652014-01-21T07:40:13Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>Thank you for clearing out what I want to say.<br>
And split up internal/external sounds good idea.<br>
(both document will be public)</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=444692014-01-21T09:32:26Zzzak (zzak _)
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Assigned</i></li></ul><p>Thank you both for the feedback, I'm going to apply your suggestions and ping back when its ready.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=448132014-01-30T06:17:25Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Target version</strong> changed from <i>2.1.0</i> to <i>2.2.0</i></li></ul> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=448652014-01-31T20:53:58Zzzak (zzak _)
<ul></ul><p>I've updated the pull request given Martin and narsue's feedback. Please check it.</p>
<p><a href="https://github.com/zzak/www.ruby-lang.org/blob/future_release_policy/en/news/_posts/2014-01-13-approved-maintenance-policy.md" class="external">https://github.com/zzak/www.ruby-lang.org/blob/future_release_policy/en/news/_posts/2014-01-13-approved-maintenance-policy.md</a></p>
<p>My plan is to write a separate document in the redmine wiki for internal policy.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=451482014-02-14T09:20:22Znaruse (Yui NARUSE)naruse@airemix.jp
<ul></ul><p>Zachary Scott wrote:</p>
<blockquote>
<p>I've updated the pull request given Martin and narsue's feedback. Please check it.</p>
<p><a href="https://github.com/zzak/www.ruby-lang.org/blob/future_release_policy/en/news/_posts/2014-01-13-approved-maintenance-policy.md" class="external">https://github.com/zzak/www.ruby-lang.org/blob/future_release_policy/en/news/_posts/2014-01-13-approved-maintenance-policy.md</a></p>
<p>My plan is to write a separate document in the redmine wiki for internal policy.</p>
</blockquote>
<blockquote>
<p>We've decided our plans for ruby-core supported maintenance periods of Ruby.</p>
</blockquote>
<p>Who are "We"?</p>
<blockquote>
<p>For context, you should read our recent policy changes for semantic versioning.</p>
</blockquote>
<p>Ruby's versioning policy is not correct "semantic versioning" because Ruby breaks compatibility in minor.<br>
Don't use this word without detailed notes.</p>
<blockquote>
<p>An approved commercial party may be able to accept responsibility of maintaining an End-of-Life version.</p>
</blockquote>
<p>This sentence should be removed.</p>
<blockquote>
<p>It's important to recognize the maintainer for each version may decide they can no longer support a version, in which case ruby-core would work to responsibly discontinue the version.</p>
</blockquote>
<p>useless sentence</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=451762014-02-15T11:59:58Zzzak (zzak _)
<ul></ul><blockquote>
<blockquote>
<p>We've decided our plans for ruby-core supported maintenance periods of Ruby.</p>
</blockquote>
</blockquote>
<blockquote>
<p>Who are "We"?</p>
</blockquote>
<p>Who should "we" be? As an official post on ruby-lang.org, it must refer to ruby-core? Should it read:</p>
<p>The ruby-core team has decided plans for supported maintenance periods of Ruby.</p>
<p>How is that?</p>
<blockquote>
<p>Ruby's versioning policy is not correct "semantic versioning".</p>
</blockquote>
<p>So just rephrasing this to:</p>
<p>For context, you should read about our recent changes to the Ruby versioning policy."</p>
<p>Furthermore:</p>
<blockquote>
<blockquote>
<p>An approved commercial party may be able to accept responsibility of maintaining an End-of-Life version.</p>
</blockquote>
</blockquote>
<blockquote>
<p>This sentence should be removed.</p>
</blockquote>
<p>And:</p>
<blockquote>
<blockquote>
<p>It's important to recognize the maintainer for each version may decide they can no longer support a version, in which case ruby-core would work to responsibly discontinue the version.</p>
</blockquote>
</blockquote>
<blockquote>
<p>useless sentence</p>
</blockquote>
<p>Are both stated to enforce how ruby-core will handle end-of-life responsibly, which is what you suggested before:</p>
<blockquote>
<p>What do you want to say in these paragraph?<br>
If this is announce, the audience is users.<br>
They read this, "We want to avoid sudden death".<br>
"ah, ok... and what ruby-core will do?"</p>
</blockquote>
<p>However, I think this paragraph:</p>
<blockquote>
<p>It's important to recognize the maintainer for each version may decide they can no longer support a version, in which case ruby-core would work to responsibly discontinue the version.</p>
</blockquote>
<p>Could be rephrased to simply:</p>
<blockquote>
<p>When support is discontinued unexpectedly ruby-core will work to support for a reasonable time until it can be End-of-Life, or an approved commercial party is able to accept maintenance of said version.</p>
</blockquote>
<p>I want to reinforce what actions we plan to take to handle discontinuation of a version.</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=456942014-03-08T21:50:40Zzzak (zzak _)
<ul></ul><p>@nurse: ping!</p>
<p>Could you review my comments? I'd like to move on from this :)</p> Ruby master - Misc #9215: Maintenance Policy for Future Releases (2.1.0 & beyond)https://bugs.ruby-lang.org/issues/9215?journal_id=472142014-06-14T00:09:06Zzzak (zzak _)
<ul><li><strong>Status</strong> changed from <i>Assigned</i> to <i>Closed</i></li></ul><p>I've migrated my (pending) NEWS document from <a href="http://www.r-l.o" class="external">www.r-l.o</a> to the wiki: <a href="https://bugs.ruby-lang.org/projects/ruby/wiki/GeneralMaintenancePolicy" class="external">GeneralMaintenancePolicy</a></p>
<p>Please make any changes to the wiki directly, if you need access ping <a class="user active user-mention" href="https://bugs.ruby-lang.org/users/572">@hsbt (Hiroshi SHIBATA)</a>.</p>