DISQUS

Julik · 1 year ago

There are more issues at play here. First of all, the Ruby core developers have this habit of only stating their intentions in Japanese on their own mailing list. Nobody ever warned the Rails core team about the fact that 1.8.7 will eat up Chars. When Manfred and I discovered the breakage it was already too late. Never have the Ru y developers considered the implications of them reclaiminv the chars method for the core String. If you followed the recent Ruby security fiasco with official update killing everything from Mongrel to god knows what...

dkubb · 1 year ago

Not to start a flame war or anything, but is it really the responsibility of the Ruby core developers have to know all of the ways Rails extending core classes so they know when it's necessary to warn people about their upcoming changes? On the other hand, the Ruby core team has a wealth of unit tests from popular projects like Rails and RubySpec to run tests with to see if their pending changes are going to break anything.

I'm sort of in the middle on the issue. Ruby core devs could do alot better job testing against popular ruby projects, while Rails core devs could do alot better job of not extending core classes when other options are available.

Julik · 1 year ago

I can assure you that when we created the String#chars method this has been publicly praised as the good choice. We've chosen a very specific method for a plethora of functionality that needd to be integrated in a safe way, and to blend it into the language we've used _one_ method.

The decision to do it like this was weighted and discussed and approved by quite some people as the most appropriate for the case.

If Ruby Core would care _at all_ about ActiveSupport (which is now the widest deployed gem in the world I think) they would think twice before introducing it in the version of the language without Unicode support.

bubuntu · 1 year ago

macports sucks, I miss my ubuntu

comctrl6 · 1 year ago

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.

nicholas a. evans · 1 year ago

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.

Alexandr Ciornii · 1 year ago

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.

patch management software · 1 year ago

Well thanks for this guide on patching Rails

Michael patch manager · 12 months ago

Thanks mate.

Michael