[development] death to "x.y.z" version is now inevitable
drupal at dwwright.net
Wed Nov 15 08:23:28 UTC 2006
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.
advanced issue search lets you filter by Versions (and the often
requested filtering on Components).
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:
> In any event, the version number for feature requests is sort of
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. 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.
 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
More information about the development