Hello, On Jun 18, 8:16 ¨Βν¬ ΥςαβΣθωουθει Όσθωου®®®ΐςυβωμαξη®οςηΎ χςοτεΊ > I think I was called :) Thank you for the input. :) > > 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. ¨Βθιχανω ζαυμτ® ¨Β σθουμδ > 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. ¨Βυτ πμεασε αμσο ξοτε τθατ χε αςξοαμχαωσ ποσσιβμε > to disclose then immediately. ¨Βεγυςιτιξγιδεξταςτςεατεβασεοξ > international concord; ¨Βοτ ζυμμγοξτςομμεδ βω υσ> > > 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? ¨ΒατγθμεφεΆςεμεασεσΆ ¨απαςτ ζςον τθοσταησ> 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. ¨Β§ν γυςςεξτμναξαηιξη τθατ λιξδ οζ μιστ βω θαξδ > (accessible viahttp://coderepos.org/share/browser/docs/shyouhei/ruby%20development/r...). Ah, the release schedule is good to know. I'm sure some of the concerns here will be addressed by having a single good source of information about the process for all the non-Japanese speakers. Having this wiki page would be awesome. > > > 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." ¨ΒοΏ Yes, I think this situation worked out well. My concern is that we continue to catch these issues before releases. Which means figuring out how to run the RubySpecs against the development branch "head" for each version 1) without causing a lot of churn in the specs (i.e. a bunch of specs had to be modified to not fail after the convert_type change), and 2) without causing confusion from failing specs for issues that have been fixed. In the first case, I think we should only add ruby_bug guards for failures in a released patchlevel of a particular version, but never for issues that exist in the development branch for that version. Does that sound reasonable? In the second case, if we only add ruby_bug guards for released versions, then any specs that fail in the development branch might be bugs? In that case, we should file tickets on the new tracker? Will this lead to a lot of work for everyone? Or is there a better way to recommend that we handle this? Thanks, Brian