« Return to Thread: [ruby-core:17327] A plea for a release process
[ruby-core:17338] Re: A plea for a release process
by Urabe Shyouhei-4
::
Rate this Message:
I think I was called :)
The reasons why I committed so much was:
1) I wanted to fix as much bugs in 1.8.5 as possible, before it expires.
2) Sadly I was busy for a while so there were many bugs stacked, and at
last I got time to touch them in 3 June. This was my fault. I should
have done this more frequently, little by little.
Brian Ford wrote:
> 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.
>
They are already. But please also note that we are not always possible
to disclose then immediately. Security incidents are treated based on
international concord; not fully controlled by us.
> 2. A regular schedule of patchlevel releases on some reasonable
> timetable (one month, two months?). For each of these scheduled
> releases:
>
Maybe I've not said this? Patchlevel "releases" (apart from those tags)
are released every 3 months normally in Mar, Jun, Sep, Dec, except for
security fixes of course. We did not released 1.8 patchlevels on last
Dec because we released 1.9.0 instead.
> 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.
>
We should have this. I'm currently managing that kind of list by hand
(accessible via
http://coderepos.org/share/browser/docs/shyouhei/ruby%20development/revisions.txt).
> 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.
That is a nice idea.
> 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).
>
What recently happened there was actually "the community to be aware of
what is planned to be released." No?
The reasons why I committed so much was:
1) I wanted to fix as much bugs in 1.8.5 as possible, before it expires.
2) Sadly I was busy for a while so there were many bugs stacked, and at
last I got time to touch them in 3 June. This was my fault. I should
have done this more frequently, little by little.
Brian Ford wrote:
> 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.
>
They are already. But please also note that we are not always possible
to disclose then immediately. Security incidents are treated based on
international concord; not fully controlled by us.
> 2. A regular schedule of patchlevel releases on some reasonable
> timetable (one month, two months?). For each of these scheduled
> releases:
>
Maybe I've not said this? Patchlevel "releases" (apart from those tags)
are released every 3 months normally in Mar, Jun, Sep, Dec, except for
security fixes of course. We did not released 1.8 patchlevels on last
Dec because we released 1.9.0 instead.
> 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.
>
We should have this. I'm currently managing that kind of list by hand
(accessible via
http://coderepos.org/share/browser/docs/shyouhei/ruby%20development/revisions.txt).
> 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.
That is a nice idea.
> 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).
>
What recently happened there was actually "the community to be aware of
what is planned to be released." No?
« Return to Thread: [ruby-core:17327] A plea for a release process
| Free embeddable forum powered by Nabble | Forum Help |
