> they're the author's responsibility. In the event we break some
> plugin, the author can let us know if it's something we didn't mean to
> do. If it breaks because it relies on the internals of rails, then
> they can release a new version.
The idea is not to fallback on the core team for each and every detail.
Well this post is out of the scope of the tiny CI stuff we've been discussing, but here's my opinion:
Given the dynamic nature of ruby, it's essentially more likely (compared to other platforms) to have some code which fiddles with the internals or externals of the core, even when you take care of not fiddling.
Although the plugin author makes effort by packaging and releasing his stuff to the community, not every plugin author will be able to support and maintain his work on the mid or long term. As everyone here knows, the coding part is only a slice in the lifetime of a piece of code, a tiner slice than maintenance part.
If releasing a plugin costs too much to the author, we'll get less plugins (read: less long-living plugins which we can rely on, or advise to a customer for instance).
Any way to ease the lives of the plugins maintainers will bring love to the users. The users need to be able to trusts those plugins (not only today, but at least in a couple of months).
I think the community will get more benefits if we think a bit more "global" - plugins are a (big) part of rails, not finding a way to bring love to them is bad for rails itself.
Just some thoughts - I really love working on Rails apps, I just want to keep it that way :)
cheers
Thibaut
--
[blog] www.dotnetguru2.org/tbarrere
_______________________________________________ Rails-core mailing list [email protected] http://lists.rubyonrails.org/mailman/listinfo/rails-core
