Hi,
Now that acts_as_nested_set has been moved to a plugin, there has been talk on the Better Nested Set mailing list of merging our work into the official rails plugin. Before I put a patch together, I wanted to ask if the core team would be receptive to this. Is the official acts_as_nested_set plugin simply there for backwards compatibility, or does the core team want to see it beefed up and improved?
Krishna
Now that acts_as_nested_set has been moved to a plugin, there has been talk on the Better Nested Set mailing list of merging our work into the official rails plugin. Before I put a patch together, I wanted to ask if the core team would be receptive to this. Is the official acts_as_nested_set plugin simply there for backwards compatibility, or does the core team want to see it beefed up and improved?
I think our position is that we'd prefer to keep the current plugins as-is, but encourage people to start new derivative plugins that can see further development, which then doesn't have to be backwards compatible.
Am I the only person saddened by this? (Judging by the lack of other responses to the thread, the answer may well be "yes". If so, please indicate your continued non-sadness by, um, not responding, I guess...)
IIRC, this policy wasn't really discussed much when it was adopted - it sort of just got announced as "we think we're going in that direction" and then nobody (else) objected. Obviously, the core team can do whatever it wants, but I'd love to at least see some debate about it.
I understand the reticence to "bless" a particular plugin that's no longer part of core. On the other hand, as Rails matures, there's an awful lot of functionality that either starts to or ceases to align with the core team's needs and interests, and it's only natural that various plugins move in and out of core. Yet by freezing them and forcing all development to continue as a project fork, you're effectively squandering their mindshare. And these certainly aren't the last plugins you'll later decide aren't a good fit for core.
In some sense, that may be what you want - it was withering away in core, so let a thousand flowers bloom and all that. Yet, to argue from absurdity, I haven't seen anyone suggest that Rails would be improved by freezing 1.2.6, and calling 2.0 something else. If you're spinning something off because the core team's not interested in maintaining it, yet there IS an active group of interested maintainers, something seems wrong.
I'm also jaded from seeing the same thing happen at a corporate level - big company likes technology, big company buys technology, technology is now only small part of big company and quickly gets subsumed. It is, in a way, a disincentive to being made part of core; you'll get a lot of mindshare early on, but later, you can be just as quickly abandoned, worse off than you were before (unless you consider a name change to be "no big deal", in which case, again, I point you to the "rename Rails" argument).
I wish I could enunciate my objection better, but for lack of that, I'll just repeat: Something seems wrong. There oughta be a better way.
The specific question is:
Do you expect continued development by the core team of the acts_as_nested_set plugin?
But here are the more general questions about plugins and rails core:
I'm a bit confused about which plugins are going to be officially supported by the core team as rails goes forward.
I'm not taking any position right now on which should be but if the code is in the rails subversion repository then the only people who can make commits are the core team.
Are there a set of plugins which should continue to work for the 1.2.x series but which are deprecated for 2.x?
Are there a set of plugins which should continue to work for the 2.x series (extracted from code which was in core in the 1.2.x series) but which will be deprecated for 3.0?
Is the core team trying to head in a direction so that there are no plugins in the rails repository for future rails versions -- instead having the plugin hosting ecosystem be distributed outside the core rails repository?
Right now there are about 21 plugins in the rails repository (link to trac view below):
http://dev.rubyonrails.org/browser/plugins
and another 4 in the legacy directory.
In the last three months only seven plugins have seen changesets:
exception_notification token_generator acts_as_list in_place_editing acts_as_tree auto_complete acts_as_nested_set
There are four that haven't been touched in 2 years:
localization deadlock_retry ssl_requirement scriptaculous_slider
and another 5 that haven't been touched in the last year.
upload_progress javascript_test account_location continuous_builder http_authentication
How many of these plugins work with 2.0 and is new functionality planned for any of them?
In some sense, that may be what you want - it was withering away in core, so let a thousand flowers bloom and all that. Yet, to argue from absurdity, I haven't seen anyone suggest that Rails would be improved by freezing 1.2.6, and calling 2.0 something else. If you're spinning something off because the core team's not interested in maintaining it, yet there IS an active group of interested maintainers, something seems wrong.
I guess I don't see this as a huge issue. The mistake was probably adding it to the framework in the first place, it clearly wasn't particularly well tested, nor was it fully featured. If the two alternatives are:
* Ship unmaintained code while better stuff is available * Provide the old code to people who depend on it, but let a thousand flowers bloom.
If there's an obvious successor to any of these plugins, we can update the README to tell people what they should be installing.
My first choice would be to allow, even encourage, the group who does want to maintain and extend nested set functionality for Rails to add their improvements to the official rails nested set plugin. That would be the easiest way for anyone needing that sort of fundamental data structure/modeling support to find a community consensus solution to the problem.
If that is too fraught, then nominating a successor (better nested set? it is what I use and have been fairly happy with) in the nested set README would be a decent second choice. What I would not like to see happen is the standard scenario where there are 10 plugins for doing XXX, but everyone uses Y - or used to. The new cool tool is Z but you have to have been hanging out listening to the discussion of XXX for you to know that the wind is blowing towards Z (and that you should ignore Y as ‘good in its day’ but on it’s way out).
My first choice would be to allow, even encourage, the group who does want to maintain and extend nested set functionality for Rails to add their improvements to the official rails nested set plugin. That would be the easiest way for anyone needing that sort of fundamental data structure/modeling support to find a community consensus solution to the problem.
Part of the problem is that the current members of the core team simply don't use nested_set enough to make good decisions about what patches should and shouldn't be applied. This same problem applies to picking maintainers for the successor-plugin. I think we're better off with alternative plugins gaining organic acceptance rather than having us make some arbitrary decision to bless a given plugin, even though we don't use it.
If it becomes 'obvious' to everyone concerned that there's a single better option, then we can reference it.
Sometimes plugins become obvious like this (will_paginate), other times they're far from clear (all the i18n/l10n plugins).
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks