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

[Derek Wright]

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 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 that's specific to our policy, not something  
inherent in issue tracking.  late in the 6.x development cycle we'll  
still accept small features for 6.x, but some feature requests will  
be considered too big, and we'll want to bump those to 7.x...

> So I took another look at the tracker, and realized that you can't  
> limit the search to a specific version or set of versions (not even  
> on the advanced search page), though you can sort the results by  
> version.  You can limit a search to just feature requests.

http://drupal.org/project/issues/search/3060
advanced issue search lets you filter by Versions (and the often  
requested filtering on Components).

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

you can also construct URLs to filter exactly what you want:
http://drupal.org/project/issues? 
projects=3060&versions=94737,94702,96923

> 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. ;)

> - there's no guarantee that it will make it into 6.  I'd hate to  
> think that when 6 is feature-frozen and 7.x-dev opened, the  
> remaining feature requests will need to be bumped to the new version.

we could certainly make an admin interface to automatically  
reclassify issues based on a query to do this operation en masse.

> I'd rather just say that the version number on an open feature  
> request is meaningless, so don't sweat it; use the date to figure  
> out how long the request has been outstanding.  When the request is  
> finally implemented and closed, then the version number becomes  
> meaningful and should be the version in which it first appears.

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].  short of that, i agree  
that the single version field for feature requests isn't worth  
sweating over.  since you can always change an issue's version in a  
follow-up, i say you set it to whatever version you'd like to see it  
in, and if it ever gets implemented, it can be reset to the version  
it was fixed in.

-derek


[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 adding a "port" category would also help that, and would be a  
lot less code to change: http://drupal.org/node/97571).  in theory,  
if we had 2 fields, they could both be N versions.  we should look  
into issue relationships, and sub-issues for each particular version  
and patch (which would be great if the UI was good enough to make it  
easy to keep track of everything).  all OT from the current x.y.z  
debates, however...