[development] death to "x.y.z" version is now inevitable

Derek Wright 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- 

>> 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  

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  
nids.</bitter-old-man> ;)


More information about the development mailing list