Comments on: The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/ "...the three great virtues of a programmer: laziness, impatience, and hubris." -- Larry Wall Wed, 03 Mar 2010 21:56:22 -0800 http://wordpress.org/?v=2.8.5 hourly 1 By: Michael patch manager http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-196 Michael patch manager Sat, 08 Nov 2008 06:02:57 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-196 Thanks mate.<br><br>Michael Thanks mate.

Michael

]]> By: patch management software http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-180 patch management software Thu, 23 Oct 2008 10:55:10 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-180 Well thanks for this guide on patching Rails Well thanks for this guide on patching Rails

]]> By: Recent Faves Tagged With "unmaintained" : MyNetFaves http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-164 Recent Faves Tagged With "unmaintained" : MyNetFaves Wed, 01 Oct 2008 23:50:27 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-164 [...] public links >> unmaintained The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 First saved by HotPinkMidNite | 2 days ago Removed unmaintained translations. First saved by [...] [...] public links >> unmaintained The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 First saved by HotPinkMidNite | 2 days ago Removed unmaintained translations. First saved by [...]

]]> By: Alexandr Ciornii http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-162 Alexandr Ciornii Sat, 27 Sep 2008 07:30:39 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-162 Such problem (adding new reserved words that may break compatibility) in Perl 5.10 was solved be adding new pragma. This pragma is automatically activated when you specify that minimum version of Perl for this module (or main program) is 5.10 or by other means. Such problem (adding new reserved words that may break compatibility) in Perl 5.10 was solved be adding new pragma. This pragma is automatically activated when you specify that minimum version of Perl for this module (or main program) is 5.10 or by other means.

]]> By: Recent Links Tagged With "rubygems" - JabberTags http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-160 Recent Links Tagged With "rubygems" - JabberTags Thu, 25 Sep 2008 14:34:05 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-160 [...] public links >> rubygems Re: The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 Saved by danacurrie on Tue 23-9-2008 I can’t upgrade RubyGems from 1.1.1 to 1.2.0 on Ubuntu [...] [...] public links >> rubygems Re: The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 Saved by danacurrie on Tue 23-9-2008 I can’t upgrade RubyGems from 1.1.1 to 1.2.0 on Ubuntu [...]

]]> By: Websites tagged "monkey" on Postsaver http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-159 Websites tagged "monkey" on Postsaver Mon, 22 Sep 2008 14:32:10 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-159 [...] - The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 saved by tenshi7892008-09-20 - Meet the Regulars saved by Patpaticio2008-09-18 - Songs That Rocked [...] [...] – The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7 saved by tenshi7892008-09-20 – Meet the Regulars saved by Patpaticio2008-09-18 – Songs That Rocked [...]

]]> By: nicholas a. evans http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-110 nicholas a. evans Sun, 10 Aug 2008 13:32:25 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-110 I'd like to add to comctrl6's comment on the "nasty habit of trying to keep my software up to date". I think this is probably another place where MacPorts has failed you... As you know, Ubuntu and Debian (as well as RedHat, SUSE, etc) have the concept of a "stable" release and a "development" or "bleeding edge" release. And the distribution teams take great pains to keep abreast of the various versions of the packages so I don't need to... and only filter the urgent bugfixes or security patches into the stable release. And their stable releases go through several months of QA-induced feature freeze prior to release. If I want to venture out on my own with newer versions of certain packages than are in the stable distro, then I take some of that responsibility onto myself... for just those several packages! But by and large, I can trust the distro maintainers to shield me from patch releases that are really minor upgrades in areas that I need stability. While there may be no technical reason that MacPorts (and e.g. Gentoo and RubyGems) can't follow this approach... in my experience, they just *don't*. And that would be fine if I had all the time in the world (in college I always used Debian unstable), but these days I'd rather be getting things done. So, while MacPorts' lack of a downgrade path is unfortunate, I would suggest that the bigger problem is that there is no stable upgrade path. And while the distros do sometimes make mistakes with their stable releases, at least they are an additional buffer between me and upstream. I’d like to add to comctrl6’s comment on the “nasty habit of trying to keep my
software up to date”. I think this is probably another place where MacPorts
has failed you…

As you know, Ubuntu and Debian (as well as RedHat, SUSE, etc) have the concept
of a “stable” release and a “development” or “bleeding edge” release. And the
distribution teams take great pains to keep abreast of the various versions of
the packages so I don’t need to… and only filter the urgent bugfixes or
security patches into the stable release. And their stable releases go through
several months of QA-induced feature freeze prior to release.

If I want to venture out on my own with newer versions of certain packages than
are in the stable distro, then I take some of that responsibility onto
myself… for just those several packages! But by and large, I can trust the
distro maintainers to shield me from patch releases that are really minor
upgrades in areas that I need stability.

While there may be no technical reason that MacPorts (and e.g. Gentoo and
RubyGems) can’t follow this approach… in my experience, they just don’t.
And that would be fine if I had all the time in the world (in college I always
used Debian unstable), but these days I’d rather be getting things done.

So, while MacPorts’ lack of a downgrade path is unfortunate, I would suggest
that the bigger problem is that there is no stable upgrade path. And while the
distros do sometimes make mistakes with their stable releases, at least they
are an additional buffer between me and upstream.

]]> By: nicholas a. evans http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-136 nicholas a. evans Sun, 10 Aug 2008 11:32:25 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-136 I'd like to add to comctrl6's comment on the "nasty habit of trying to keep my<br>software up to date". I think this is probably another place where MacPorts<br>has failed you...<br><br>As you know, Ubuntu and Debian (as well as RedHat, SUSE, etc) have the concept<br>of a "stable" release and a "development" or "bleeding edge" release. And the<br>distribution teams take great pains to keep abreast of the various versions of<br>the packages so I don't need to... and only filter the urgent bugfixes or<br>security patches into the stable release. And their stable releases go through<br>several months of QA-induced feature freeze prior to release.<br><br>If I want to venture out on my own with newer versions of certain packages than<br>are in the stable distro, then I take some of that responsibility onto<br>myself... for just those several packages! But by and large, I can trust the<br>distro maintainers to shield me from patch releases that are really minor<br>upgrades in areas that I need stability.<br><br>While there may be no technical reason that MacPorts (and e.g. Gentoo and<br>RubyGems) can't follow this approach... in my experience, they just *don't*.<br>And that would be fine if I had all the time in the world (in college I always<br>used Debian unstable), but these days I'd rather be getting things done.<br><br>So, while MacPorts' lack of a downgrade path is unfortunate, I would suggest<br>that the bigger problem is that there is no stable upgrade path. And while the<br>distros do sometimes make mistakes with their stable releases, at least they<br>are an additional buffer between me and upstream. I'd like to add to comctrl6's comment on the "nasty habit of trying to keep my<br>software up to date". I think this is probably another place where MacPorts<br>has failed you…<br><br>As you know, Ubuntu and Debian (as well as RedHat, SUSE, etc) have the concept<br>of a "stable" release and a "development" or "bleeding edge" release. And the<br>distribution teams take great pains to keep abreast of the various versions of<br>the packages so I don't need to… and only filter the urgent bugfixes or<br>security patches into the stable release. And their stable releases go through<br>several months of QA-induced feature freeze prior to release.<br><br>If I want to venture out on my own with newer versions of certain packages than<br>are in the stable distro, then I take some of that responsibility onto<br>myself… for just those several packages! But by and large, I can trust the<br>distro maintainers to shield me from patch releases that are really minor<br>upgrades in areas that I need stability.<br><br>While there may be no technical reason that MacPorts (and e.g. Gentoo and<br>RubyGems) can't follow this approach… in my experience, they just don't.<br>And that would be fine if I had all the time in the world (in college I always<br>used Debian unstable), but these days I'd rather be getting things done.<br><br>So, while MacPorts' lack of a downgrade path is unfortunate, I would suggest<br>that the bigger problem is that there is no stable upgrade path. And while the<br>distros do sometimes make mistakes with their stable releases, at least they<br>are an additional buffer between me and upstream.

]]> By: comctrl6 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-109 comctrl6 Sat, 09 Aug 2008 22:17:56 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-109 I see a few problems here: 1. The Ruby development team included an API change (a new method) to a patch release. This should not have been done. 2. "The nasty habit" of updating and staying on the cutting edge also contributed to this problem. This isn't just a problem with Avidi, but I have also been bitten by that bad habit. 3. The Ruby language does not have a well defined spec and test case suit, which leads into problems like these. 4. Blaming the Rails development team for using a language feature (albeit an often discouraged one) is wrong. I offer the following to try to remedy the situation: 1. Path releases should be just that. No new features should be introduced in a z (as in x.y.z) release. 2. If one does not need what a new version of any software package provides, there is no need to upgrade. However, it's an assumed fact in the open source software world that a patch release is, more often than not, safe to upgrade to, so the problem is twofold. (See 1) 3. There is rubyspec.org and all of the large Ruby based frameworks and libraries have reliable and fairly complete test suites that can be run against a Ruby release. Obviously the Ruby development team failed to test an unusual release with all the available test suites. I don't have to tell anyone how important testing is, specially when you have pretty a lot of customers. 4. Thought it is a discouraged practice, for better or worse, the ability to extend the core library (or any already defined class) is a built-in language feature of Ruby and using it should not draw criticism towards the Rails development team. This just my opinion on the matter. I see a few problems here:

1. The Ruby development team included an API change (a new method) to a patch release. This should not have been done.

2. “The nasty habit” of updating and staying on the cutting edge also contributed to this problem. This isn’t just a problem with Avidi, but I have also been bitten by that bad habit.

3. The Ruby language does not have a well defined spec and test case suit, which leads into problems like these.

4. Blaming the Rails development team for using a language feature (albeit an often discouraged one) is wrong.

I offer the following to try to remedy the situation:

1. Path releases should be just that. No new features should be introduced in a z (as in x.y.z) release.

2. If one does not need what a new version of any software package provides, there is no need to upgrade. However, it’s an assumed fact in the open source software world that a patch release is, more often than not, safe to upgrade to, so the problem is twofold. (See 1)

3. There is rubyspec.org and all of the large Ruby based frameworks and libraries have reliable and fairly complete test suites that can be run against a Ruby release. Obviously the Ruby development team failed to test an unusual release with all the available test suites. I don’t have to tell anyone how important testing is, specially when you have pretty a lot of customers.

4. Thought it is a discouraged practice, for better or worse, the ability to extend the core library (or any already defined class) is a built-in language feature of Ruby and using it should not draw criticism towards the Rails development team.

This just my opinion on the matter.

]]> By: comctrl6 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/comment-page-1/#comment-135 comctrl6 Sat, 09 Aug 2008 20:17:56 +0000 http://avdi.org/devblog/2008/08/07/the-trifecta-of-fail-or-how-to-patch-rails-20-for-ruby-187/#comment-135 I see a few problems here:<br><br>1. The Ruby development team included an API change (a new method) to a patch release. This should not have been done. <br><br>2. "The nasty habit" of updating and staying on the cutting edge also contributed to this problem. This isn't just a problem with Avidi, but I have also been bitten by that bad habit.<br><br>3. The Ruby language does not have a well defined spec and test case suit, which leads into problems like these.<br><br>4. Blaming the Rails development team for using a language feature (albeit an often discouraged one) is wrong.<br><br>I offer the following to try to remedy the situation:<br><br>1. Path releases should be just that. No new features should be introduced in a z (as in x.y.z) release.<br><br>2. If one does not need what a new version of any software package provides, there is no need to upgrade. However, it's an assumed fact in the open source software world that a patch release is, more often than not, safe to upgrade to, so the problem is twofold. (See 1)<br><br>3. There is <a href="http://rubyspec.org">rubyspec.org</a> and all of the large Ruby based frameworks and libraries have reliable and fairly complete test suites that can be run against a Ruby release. Obviously the Ruby development team failed to test an unusual release with all the available test suites. I don't have to tell anyone how important testing is, specially when you have pretty a lot of customers.<br><br>4. Thought it is a discouraged practice, for better or worse, the ability to extend the core library (or any already defined class) is a built-in language feature of Ruby and using it should not draw criticism towards the Rails development team.<br><br>This just my opinion on the matter. I see a few problems here:<br><br>1. The Ruby development team included an API change (a new method) to a patch release. This should not have been done. <br><br>2. "The nasty habit" of updating and staying on the cutting edge also contributed to this problem. This isn't just a problem with Avidi, but I have also been bitten by that bad habit.<br><br>3. The Ruby language does not have a well defined spec and test case suit, which leads into problems like these.<br><br>4. Blaming the Rails development team for using a language feature (albeit an often discouraged one) is wrong.<br><br>I offer the following to try to remedy the situation:<br><br>1. Path releases should be just that. No new features should be introduced in a z (as in x.y.z) release.<br><br>2. If one does not need what a new version of any software package provides, there is no need to upgrade. However, it's an assumed fact in the open source software world that a patch release is, more often than not, safe to upgrade to, so the problem is twofold. (See 1)<br><br>3. There is <a href="http://rubyspec.org">rubyspec.org</a> and all of the large Ruby based frameworks and libraries have reliable and fairly complete test suites that can be run against a Ruby release. Obviously the Ruby development team failed to test an unusual release with all the available test suites. I don't have to tell anyone how important testing is, specially when you have pretty a lot of customers.<br><br>4. Thought it is a discouraged practice, for better or worse, the ability to extend the core library (or any already defined class) is a built-in language feature of Ruby and using it should not draw criticism towards the Rails development team.<br><br>This just my opinion on the matter.

]]>