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

[Gary Feldman]

Derek Wright wrote:
> On Nov 14, 2006, at 12:09 PM, Gary Feldman wrote:
>> This seemed suspicious to me, because it makes 6.x-dev redundant with 
>> the feature request category.
> only in the short term.  in a few months, people will be reporting 
> bugs against the new menu system chx will be building for D6. ;) don't 
> confuse
Well, yes, but that changes the premise of your original note, which 
said that 6.x-dev should only be used for feature requests.  I thought 
it was implicit that my comment only applied to that situation, and not 
after 6.x-dev becomes appropriate for bugs.
> the type (feature vs. task vs. bug) with the version.  by convention 
> we only accept feature requests for a specific version at any given 
> time, but
What does this convention mean?  My guess is that you mean features are 
only committed to CVS for one specific version at any time, since 
clearly someone can submit a feature request with no idea of when it 
will get done.  More specifically, what does it mean to say that a 
feature request has version 6.x-dev?  Does that mean there's agreement 
that it belongs in version 6?  Somebody has agreed to implement it for 
6?  The way I read your original note, reinforced by your remark above, 
is that all it means is that the feature request happened to be 
submitted during the 5.x feature freeze.  That doesn't seem like useful 
information; it's implicit in the date.

Here's another way of looking at it:  A person submitting a bug report 
should be able to identify a specific version that exhibits the bug, but 
a person submitting a feature request may not have a clue as to when it 
will be implemented.  In the bug case, the meaning of the version number 
is well defined and in theory should never change.  In the feature 
request case, the submitter may not know enough to choose a meaningful 
version, and hence we can't assume it has any significance at all.  
(Mozilla gets around this by only using the public tracking system for 
bugs, with feature requests going into forums.  I don't know how they 
then select features for implementation.  They're obviously a much more 
structured group, so this is just an observation, not a suggestion.)

I'm coming from the idea that at the point in time that you're ready to 
consider feature requests for a new version, you review all open feature 
requests.  At that point in time, all of the version and priority 
information is subject to change.  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.
> ...
> http://drupal.org/project/issues/3060
> it's lame that this default issue query UI doesn't let you filter on 
> those, too, and i definitely plan to fix this 
> (http://drupal.org/node/65336).  but there's only 1 of me, and i've 
> kinda been busy recently. ;)  it does at least provide a link to 
> "advanced search"...
This looks really nice.  Will it become the default issue UI soon?
> you can also construct URLs to filter exactly what you want:
> http://drupal.org/project/issues?projects=3060&versions=94737,94702,96923
Shame, shame :-)  Given the desire to improve Drupal's usability, ideas 
such as typing explicit, obscure data into the URL shouldn't be in 
anyone's repertoire anymore.  :-)  But I appreciate the suggestion.
> In any event, the version number for feature requests is sort of 
> irrelevant
>
> perhaps.  i personally think it's still useful info.  again, you just 
> need the right tools to filter and manipulate all the data.  i'm not 
> saying all our tools are perfect yet, but they're getting better. ;)
Yes, they are getting better all the time; I don't wish to disparage all 
the work that's gone into them.
> merlin and i were talking about (and webchick's question also raises) 
> the issue of needing 2 version fields "reported for" and "resolved 
> in".  that's a whole other discussion[1].
In the For What It's Worth department, both Trac and Bugzilla have a 
version field and a target field (called milestone by Trac).  
Sourceforge doesn't have any version number fields, and uses a separate 
database for feature request.  And as indicated above, Mozilla doesn't 
use Bugzilla for feature requests.  So there's a spectrum of 
approaches.  Personally, I like having the target date, with "unknown" a 
suitable initial default for feature requests.
> [1] http://drupal.org/node/66484 i'd like to someday have the version 
> be a multi-select to indicate bugs that exist in multiple branches (though
There are projects for which that makes sense, but I don't see Drupal 
ever maintaining so many branches that this becomes necessary.

Regards,
Gary