[development] death to "x.y.z" version is now inevitable
drupal at dwwright.net
Wed Nov 15 22:42:53 UTC 2006
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-
> 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
c) issue relationships are good for more than just this problem.
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
More information about the development