The following two posts (at the bottom) were posted to engine-
[email protected] and suggests further issues with 1.1.4
I’m forwarding it here for two reasons:
-
Just a heads-up that 1.1.4 breaks engines that are customised.
login/user_engine are probably almost as widely deployed as Typo, and
if you’ve done any controller-level customisation, 1.1.4 appears to
break it. The second message points out what Tim found to fix it as a
work-around, and when I get time I’ll see if I can track down the
issue and submit a patch via the usual channels. -
We all love test-driven development, but it would seem that the
core team are not getting the opportunity to drink as much of the
Koolaid as some of the rest of us. Don’t blame them - their workload
elsewhere is ridiculously high, and the quality of the tests they’re
doing to make sure rails itself stable is superb. However, as more
and more engines/plugins/apps get distributed, is is worth testing
how a rails release will work with them in the real world?
In other words, would it be worth assembling a test suite of the most
used apps and engines to test each Rails release with before
releasing? Typo was a problem last time around, and now we’re seeing
other issues pop-up - this is a problem that is going to get worse
unless it gets managed as the number of apps, plugins and other code
relying on rails increases by the day.
This way, when a rails release is about to be rolled up we can throw
a couple of thousand tests that aren’t internal to the framework at
it, so we can see if engines, or typo, or any other public-released
app, or some of the more popular plugins break on the build, and then
the core developers can use that knowledge to fix things before we
break them for ourselves? Or at least tell us “this is going to break
your app if you’re using these plugins”. Maybe even get the app/
plugin/engine developers notified automatically so they can start
patching before release?
Of course, nobody can test whether the app you’ve written yourself is
going to break with a new rails release other than you, but if we
make sure that the most popular code if working OK, we’re going to
dramatically reduce the amount of time DHH & co. have to spend
patching releases, IMHO.
Just an idea, and it seems more like what we should be doing instead
of shouting “freeze gems everybody” - it feels more Rails-y to be
making use of all that test code flying around out there.
Anybody? Or am I missing something?
If people think it’s a good idea, but don’t want to put resource into
it themselves, I’m sure I can work something up in the next week or so.
Begin forwarded message:
Will post again once I have more details.
–
Posted via http://www.ruby-forum.com/.
engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-
engines.org
Begin forwarded message:
