On Nov 15, 2006, at 2:06 PM, Gary Feldman wrote:
More specifically, what does it mean to say that a feature request has version 6.x-dev?
it just means, either: a) someone thinks it should be done in 6.x b) there's a patch attached to the issue that's compatible with the 6.x API that implements the feature when the feature is actually committed, the "RTBC >> fixed" followup can also assign the issue to the version it was actually fixed in.
That doesn't seem like useful information; it's implicit in the date.
except you can't (yet) sort anything by dates.
That's why I don't see a use for a version number in a feature request until there's an actual commitment to a version.
from the perspective just of feature requests, perhaps. but, people looking at *all* issues for 5.x want to only see feature requests that are still marked for "to-be-done-in-5.x" (of which there are currently a vanishingly small number, but that wasn't the case a few weeks ago), not the ones that have already been re-assigned to "to- big-for-5.x-we'll-look-again-in-6.x".
http://drupal.org/project/issues? projects=3060&versions=94737,94702,96923 Shame, shame :-)
at least you can cut and paste such links and share them with other people to directly see the same view of the same data. if it's all hidden in $_POST and/or $_SESSION, it's harder to show someone else what you're seeing.
There are projects for which that makes sense, but I don't see Drupal ever maintaining so many branches that this becomes necessary.
a) don't confuse core with contrib. different contrib maintainers might decide to more actively support far more branches than core does. b) even in core, bugs almost always need to be fixed in at least 2, maybe 3 branches. a "port" category will help, but it's a complete solution. c) issue relationships are good for more than just this problem. <bitter-old-man> i'd include the link to what i've written about this, but i doubt anyone's going to read it, so i won't bother finding the relevant nids.</bitter-old-man> ;) -derek