Again, that is irrelevant. It is a *patch* release, noting should be breaking. If something break:
1. We're doing it wrong. That mean some change should *not* be in the patch release. 2. I doubt people will notice it at the time of RC. again, no one uses RC on production, let alone development unless you're close to the core team. So the bug report on those plugins won't come on until the final release. I always seeing this, so I know that's how it works. I think we should stop making a big deal of patch release, doing RC only for the minor and major release, and all the patches/fixes would be delivered and tested by user faster. - Prem On Nov 15, 2011, at 8:43 AM, Wael M. Nasreddine wrote: > I believe the reason for Release Candidate is not just to test rails, but > other components as well, take this RC for example, it depends on un-released > version of sass-rails, and a new version of Sprockets even if Rails did not > introduce any regressions that doesn't mean that other components are as > safe. The core team simply cannot guarantee that it is working as expected in > any environment and for all applications. > > Wael > > On Tue, Nov 15, 2011 at 14:36, Mislav <[email protected]> wrote: > Rails 3.1.2.rc2 just got released. Around the time of the 3.1.1 release, > there was also a relatively evolved release process including announcements > and release candidates. > > Why? > > Minor releases (e.g. 2.x) and major releases (e.g. Rails 2 and Rails 3) > usually add tons of features and, even in minor releases, often include major > refactoring of some parts to improve performance and reduce code complexity. > Both features and major refactoring can introduce new bugs, so release > candidates are offered to users so they can help with development by testing > their applications on the upcoming version. > > But point releases (e.g. 3.1.x) don't add features or change too much code, > they just try to have bugfixes. Bugs are fixed by adding a failing test and > making it pass, while ensuring the rest of the test suite passes too. This > means each point release has less bugs than the previous one. Upgrading to > the newest bugfix release is quick, safe, and should be done as often as > possible. > > In other words, bugfix releases are cheap. Why waste time with release > candidates when we can just get 3.1.2 right away? Then, every fix that would > otherwise be made between 3.1.2.rc2-3.1.2 can just be released as 3.1.3. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/Xpwg9tIt2xAJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Waêl Nasreddine > TechnoGate www.technogate.fr > mobile : 06.41.68.38.35 > agence : 09.70.444.236 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
