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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Prem Sichanugrist
2011-Nov-15 13:43 UTC
Re: Why do we have release candidates for patch releases?
Agree. I was going to say this a while ago as well. It doesn''t matter if we are going to have Rails 3.1.100, it matters for us to release early and release often to make sure those fixes are in people''s hand. And by the way, after I talked to a lot of non-core guys, they usually don''t care about testing the RC. The only time they would start trying and see the bug would be the released version. -Prem Sent from my iPhone On Nov 15, 2011, at 8:36 AM, Mislav <mislav.marohnic@gmail.com> 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Wael M. Nasreddine
2011-Nov-15 13:43 UTC
Re: Why do we have release candidates for patch releases?
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 <mislav.marohnic@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Prem Sichanugrist
2011-Nov-15 14:01 UTC
Re: Why do we have release candidates for patch releases?
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 <mislav.marohnic@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Nicolás Sanguinetti
2011-Nov-15 14:04 UTC
Re: Why do we have release candidates for patch releases?
Rails never quite followed SemVer (call it what you will), though. -foca On Tue, Nov 15, 2011 at 12:01 PM, Prem Sichanugrist <sikandsak@gmail.com> wrote:> 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 <mislav.marohnic@gmail.com> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Prem Sichanugrist
2011-Nov-15 14:09 UTC
Re: Why do we have release candidates for patch releases?
I know, I always find it irritating, but I think the core team are now trying hard to. :) - Prem On Nov 15, 2011, at 9:04 AM, Nicolás Sanguinetti wrote:> Rails never quite followed SemVer (call it what you will), though. > > -foca > > On Tue, Nov 15, 2011 at 12:01 PM, Prem Sichanugrist <sikandsak@gmail.com> wrote: >> 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 <mislav.marohnic@gmail.com> 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 rubyonrails-core@googlegroups.com. >>> To unsubscribe from this group, send email to >>> rubyonrails-core+unsubscribe@googlegroups.com. >>> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Ken Collins
2011-Nov-15 14:42 UTC
Re: Why do we have release candidates for patch releases?
I have seen previous tiny version releases break the SQL Server adapter. Which to me points out two things, the scope and size of the rails stack and the nasty hacks I have had to do to pass the ActiveRecord test suite. In general I agree that tiny version releases should not need release candidate gems. On the flip side, I appreciate that core is making an effort to warn upfront too and I think the RC process has value. In my case, it is easy to automate my tests on that git tag or a bundled download. - Ken -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
James B. Byrne
2011-Nov-15 15:02 UTC
Re: Why do we have release candidates for patch releases?
On Tue, November 15, 2011 09:42, Ken Collins wrote:> > I have seen previous tiny version releases break the SQL > Server adapter. Which to me points out two things, the > scope and size of the rails stack and the nasty hacks I > have had to do to pass the ActiveRecord test suite. > > In general I agree that tiny version releases should not > need release candidate gems. On the flip side, I > appreciate that core is making an effort to warn upfront > too and I think the RC process has value. In my case, it > is easy to automate my tests on that git tag or a bundled > download. > >Versioning software can be a bureaucratic nightmare. It can also be a swamp in which no-one knows exactly what it means. To avoid the latter without advocating the former I think it is reasonable to have some idea of what the core team presently hold as sufficient cause to change each of the Major, the Minor and the Patch numbers for RoR. Is there a guide to this criteria somewhere? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jeremy Kemper
2011-Nov-15 15:26 UTC
Re: Why do we have release candidates for patch releases?
On Tue, Nov 15, 2011 at 6:36 AM, Mislav <mislav.marohnic@gmail.com> 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? >Standardizing the process makes it easier to manage frequent releases. Pushing a candidate is part of making that process robust and repeatable. 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. >The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.) I love the spirit behind doing point releases like crazy and recovering quickly from issues with new point releases. But our experience shows that actually leads to *less frequent* releases. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Nicolas Blanco
2011-Nov-15 15:35 UTC
Re: Why do we have release candidates for patch releases?
Just for a reminder : the Rails core team used to not release pre or beta versions of minor releases. But then there was Rails 2.3.6, months after 2.3.5, which totally broke everything. Rails 2.3.7 was quickly released but was also buggy, then 2.3.8 : a total of 3 minor versions in two days. After that event, the Rails core team decided to prerelease even minor versions. -- 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/-/IoOlCm6d3roJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Robert Pankowecki
2011-Nov-15 17:01 UTC
Re: Re: Why do we have release candidates for patch releases?
RC releases are very important. If you don''t want to use them (don''t care about them), fine. I found few bugs in RC versions and used veto to reschedule their release. All of that with simply changing my Gemfile and running rake test. Robert Pankowecki -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Tuesday, November 15, 2011 4:26:34 PM UTC+1, Jeremy Kemper wrote:> > > Pushing a candidate is part of making that process robust and repeatable. >It''s bizarre that pushing *more* releases makes the act of pushing releases easier. The candidates are to avoid release screwups, not to capture every last> possible bug. (3.1.2.rc1, for example.) >I can understand why the core team tries to avoid the scenario that once led to releasing 2.3.6 + 2.3.7 + 2.3.8 in the same day. That day, developers didn''t feel to confident about those releases because first two were "screwups". But maybe there are ways to improve the release process and detect "screwups" early before pushing the actual gems out. That would eliminate the need for throwaway version numbers (i.e. RCs for patch releases). I don''t have concrete suggestions about this due to my lack of experience for releasing software at this scale. @everyone: This discussion is not about should Rails follow SemVer for their versioning policy. But Rails patch releases already conform to SemVer in a way they don''t introduce/change features. -- 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/-/tJpAHzrIGewJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2011-Nov-15 19:52 UTC
Re: Why do we have release candidates for patch releases?
> On Tuesday, November 15, 2011 4:26:34 PM UTC+1, Jeremy Kemper wrote: > > > > Pushing a candidate is part of making that process robust and repeatable. > > It''s bizarre that pushing *more* releases makes the act of pushing releases easier. > > > The candidates are to avoid release screwups, not to capture every last possible bug. (3.1.2.rc1, for example.) > > I can understand why the core team tries to avoid the scenario that once led to releasing 2.3.6 + 2.3.7 + 2.3.8 in the same day. That day, developers didn''t feel to confident about those releases because first two were "screwups". But maybe there are ways to improve the release process and detect "screwups" early before pushing the actual gems out. That would eliminate the need for throwaway version numbers (i.e. RCs for patch releases). I don''t have concrete suggestions about this due to my lack of experience for releasing software at this scale.During the 1.x and 2.x series the release process looked something like "Everyone on the core team upgrades their application, looks good, ship it". By 2.3 that was no longer feasible and, as you mentioned, we had some severe fuckups. Even during 3.0 we managed to accidentally break the router. The reality is there''s no substitute for pushing a preview release and asking people to test it, despite what the TDD evangelists may tell you :) It''s more ceremony and more work for ''us'', but the result is less breakage for ''you'' so I think that''s a good balance. -- Cheers, Koz>-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Yehuda Katz
2011-Nov-15 21:13 UTC
Re: Why do we have release candidates for patch releases?
Indeed. Advocating that we go back to what we did before is a big mistake. Releasing actual gems is the best way to make sure that people know about the impending release and have an opportunity to try it out and discover mistakes. In fact, the RC releases we have done *have* discovered mistakes. I don''t want to build a process around the assumption of no mistakes. Yehuda Katz (ph) 718.877.1325 On Tue, Nov 15, 2011 at 7:26 AM, Jeremy Kemper <jeremykemper@gmail.com>wrote:> On Tue, Nov 15, 2011 at 6:36 AM, Mislav <mislav.marohnic@gmail.com> 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? >> > > Standardizing the process makes it easier to manage frequent releases. > > Pushing a candidate is part of making that process robust and repeatable. > > > 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. >> > > The candidates are to avoid release screwups, not to capture every last > possible bug. (3.1.2.rc1, for example.) > > I love the spirit behind doing point releases like crazy and recovering > quickly from issues with new point releases. But our experience shows that > actually leads to *less frequent* releases. > > -- > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Jon Leighton
2011-Nov-15 21:55 UTC
Re: Why do we have release candidates for patch releases?
I think the fact that I messed up rc1 is testament to the fact that RCs are a good idea ;) But in general, doing releases is a big hassle. Therefore, I would prefer to encounter this hassle on my own schedule, not in the middle of the night when I''ve just messed up a ''real'' release and am racing against the clock to push out a fixed one. On Tue, 2011-11-15 at 13:13 -0800, Yehuda Katz wrote:> Indeed. Advocating that we go back to what we did before is a big > mistake. Releasing actual gems is the best way to make sure that > people know about the impending release and have an opportunity to try > it out and discover mistakes. In fact, the RC releases we have done > *have* discovered mistakes. I don''t want to build a process around the > assumption of no mistakes. > > Yehuda Katz > (ph) 718.877.1325 > > > On Tue, Nov 15, 2011 at 7:26 AM, Jeremy Kemper > <jeremykemper@gmail.com> wrote: > On Tue, Nov 15, 2011 at 6:36 AM, Mislav > <mislav.marohnic@gmail.com> 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? > > > Standardizing the process makes it easier to manage frequent > releases. > > > Pushing a candidate is part of making that process robust and > repeatable. > > > > > 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. > > > The candidates are to avoid release screwups, not to capture > every last possible bug. (3.1.2.rc1, for example.) > > > I love the spirit behind doing point releases like crazy and > recovering quickly from issues with new point releases. But > our experience shows that actually leads to *less frequent* > releases. > > >-- http://jonathanleighton.com/
Aaron Patterson
2011-Nov-15 23:50 UTC
Re: Why do we have release candidates for patch releases?
On Tue, Nov 15, 2011 at 09:55:05PM +0000, Jon Leighton wrote:> I think the fact that I messed up rc1 is testament to the fact that RCs > are a good idea ;) > > But in general, doing releases is a big hassle. Therefore, I would > prefer to encounter this hassle on my own schedule, not in the middle of > the night when I''ve just messed up a ''real'' release and am racing > against the clock to push out a fixed one.Agreed. People complained when we didn''t have rc''s, now they complain that we do. ;-) I prefer to stick with the cautious route and release RCs. It seems to be working well so far. -- Aaron Patterson http://tenderlovemaking.com/