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