Allow issues to be filed against multiple versions/branches.

This would be handy, I agree. The display of the versions in the metadata fields won't be a problem now, since the tables can accept multiple values. Upping the version since this is still very relevant.

I agree. And this would be very useful for us. :)

Another reason for tracking multiple "affected versions" is that this can be a huge factor in rapid triage. When deciding where to spend precious development resources, one important consideration is "how many releases are affected?"

Admittedly, many projects seem to move in a more or less straight line.

But some projects have multiple versions, affecting different customers. It's important to be able to filter on that data -- and not just by searching the bodies of comments.

Carlos

I too think that this would be useful, but I am reluctant due to possible implications when it comes to the UX.

I am also cross-linking/pointing out #1050616: Figure out backport workflow from Drupal 8 to Drupal 7, because I believe is relevant.

Subscribing, we really need this instead of tags.

We could improve the UX here by only showing branches in the version drop-down - there is no reason to post issues against point releases - even if this had to be custom d.o code for core to remove the options.

Well, I am not a UX expert, but here's an idea of how the "Version" drop-down could be replaced by a "Branches" multi-select list:

 - Project information --------------------------------------------------------
|                                                                              |
|  Project:         Branches: *   Per-branch versions affected:                |
|  <project_name>   [ ] 7.x        __________________________________________  |
|                   [v] 6.x       | 6.x                                      | |
|  Component: *     [v] 5.x       |_____    [v] 6.x-2.x-dev                  | |
|  [ <none>   |v]   [ ] 4.x       | 5.x |   [v] 6.x-2.1                      | |
|                                 |_____|   show more 6.x versions...        | |
|                                       |____________________________________| |
 ------------------------------------------------------------------------------

Selecting a branch from the list, enables a respective tab on the right...

 - Project information --------------------------------------------------------
|                                                                              |
|  Project:         Branches: *   Per-branch versions affected:                |
|  <project_name>   [v] 7.x        __________________________________________  |
|                   [v] 6.x       | 7.x                                      | |
|  Component: *     [v] 5.x       |_____    [v] 7.x-1.x-dev                  | |
|  [ <none>   |v]   [ ] 4.x       | 6.x |   [v] 7.x-1.0                      | |
|                                 |_____|   show more 7.x versions...        | |
|                                 | 5.x |                                    | |
|                                 |_____|____________________________________| |
 ------------------------------------------------------------------------------

Each branch's tab could have the latest stable + its dev (if/where available) versions pre-selected for convenience.

The "show more versions" link is there to show other hidden versions of the same branch...

 - Project information --------------------------------------------------------
|                                                                              |
|  Project:         Branches: *   Per-branch versions affected:                |
|  <project_name>   [v] 7.x        __________________________________________  |
|                   [v] 6.x       | 7.x |                                    | |
|  Component: *     [v] 5.x       |_____|   [v] 6.x-2.x-dev                  | |
|  [ <none>   |v]   [ ] 4.x       | 6.x     [v] 6.x-2.1                      | |
|                                 |_____    [ ] 6.x-2.0                      | |
|                                 | 5.x |   [ ] 6.x-2.0beta                  | |
|                                 |_____|   [v] 6.x-1.x-dev                  | |
|                                       |   [ ] 6.x-1.7                      | |
|                                       |   [ ] 6.x-1.6                      | |
|                                       |____________________________________| |
 ------------------------------------------------------------------------------

No more version switching! Instead of "But I am having this issue in version x.y.z" there'll be "I am seeing this in x.y.x too" ;)

...or we can skip the "Branches" select list and have tabs for all available branches of each project.

Each tab could also hold links to any patches available (if any) for the respective branch, ...but that's another UI issue ;)

A) yes.

B) There is mv, custom denormalization via hooks and solr. All of these are probably a huge job, but I expect the queries would be sufficiently bad they'd not be acceptable otherwise.

C) branches instead of tags would make it a smaller multi-select. Looks like klonos is suggesting hierarchical select for this.

D) probably all affected versions, and skip the sorting.

Looks like klonos is suggesting hierarchical select for this.

...not exactly. Unless of course HS allows the selection of multiple parent items besides multiple children (don't actually know this, since I never had such a use case so far).

As for how the effected versions could be displayed in the issue summary, this could be either a simple 5.x, 6.x, 7.x list (where each branch could be link that would serve as a show more/details button for each specific branch), or if we wish to make things more complicated, the list could be in the form of ranges: 5.x-min to 5.x-max, 6.x-min to 6.x-max, 7.x-min to 7.x-max (where -of course- the min and max represent the actual minimum and maximum versions verified to be effected). I doubt that for example the 6.x-1.3 through 6.x-1.7 versions would be effected and 6.x-1.5 would not - even if not specifically confirmed.

In fact, here's an updated mockup with the "Branches" select list removed and ranges of effected versions displayed as tab summaries:

 - Project information ----------------------------------------------------
|                                                                          |
|  Project:         Branches & versions affected: *                        |
|  <project_name>    ____________________________________________________  |
|                   | 7.x                    |                           | |
|                   | 7.x-1.3 to 7.x-2.1     |   [v] 6.x-2.x-dev         | |      
|  Component: *     |________________________|   [v] 6.x-2.3             | |
|  [ <none>   |v]   | 6.x                        [v] 6.x-2.2             | |
|                   | 6.x-1.7 to 6.x-2.x-dev     [v] 6.x-2.1             | |
|                   |________________________    [ ] 6.x-2.0             | |
|                   | 5.x                    |   [ ] 6.x-2.0beta         | |
|                   | (branch not effected)  |   [v] 6.x-1.x-dev         | |
|                   |________________________|   [v] 6.x-1.8             | |
|                                            |   [v] 6.x-1.7             | |
|                                            |   [ ] 6.x-1.6             | |
|                                            |__________________________ | |
 --------------------------------------------------------------------------

...I think that "through" instead of "to" makes more sense in English when referring to ranges, but you get the point ;)

...that + I'm mixing my "affected" and "effected".

Subscribing...

Also, I disagree with "there is no reason to post issues against point releases", even on d.o. If I find a bug in a specific version of a module, it's relevant and important to communicate exactly what version I'm using so that the maintainer (and others) can attempt to reproduce the bug. Although it might make sense to pull all the branches to the top of the list(s), I don't think it's a good idea to hide all the point releases entirely. Especially if this becomes multi-valued, I think it'd be great to flag bugs as being in 7.0 and 7.x-dev, then removing them from 7.x-dev once the fix has been committed (or something) so you can see which versions are affected, etc. If a bug still isn't fixed in 7.1, you'd mark it 7.0, 7.1. From my perspective, a lot of the value (although certainly not all) in making these multi-valued is to capture more precisely what versions a given bug impacts. It'd *also* be nice for tracking issues that span multiple branches, but that's not the only use-case.

This is a good point, I can think of three use-cases the field supports then:

* Currently the version really means 'target version'. Sometimes maintainers want a decent patch for more than one branch, but often you can post against one branch, get that committed, then work on the backport (or forward port depending on the project) afterwards. It's also the version that tests run against etc.

* For tracking multiple releases it'd mean "affected versions", this is what the 'needs backport' tags abuse is for - although it's not possible to do lists like WHERE (version = '8.x' AND issue_tag = 'Needs backport to D7') OR 'version = 7.x', so it's a bit unwieldy.

* This is a bit different to "fixed in versions". For example there are a tonne of views patches that have been committed in the past year, that weren't in the security release, but they've been marked fixed/closed - and before that release came out. In an ideal world, we could base the automated change from fixed to closed based on whether the issue has been fixed in a stable release or not. That's a different feature request again but it's related.

If we left the current version as 'target version', it wouldn't be inconceivable to add nodereferences for affected and fixed - but that's going to make for an even more complicated form, and there is still listing and query performance (although if it's not the default listing it might be a tiny bit less critical if they're a bit slow).

In #1050616-117: Figure out backport workflow from Drupal 8 to Drupal 7, @fietserwin suggested to simply have two fields: "version reported" and "version targeted". The latter being the current version field.

I like that proposal because of its simplicity. But of course, it presumes some built-in internal knowledge about release relationships and history. Reporting a bug against 6.x-1.1 and targeting 6.x-1.x would naturally imply that 6.x-1.1, 6.x-1.2, 6.x-1.3, ... and 6.x-1.x are affected. Switching the target to 7.x-1.x would additionally imply that possibly existing 7.x-1.0, 7.x-1.1, etc are affected, too.

Thinking further, it could also be three fields, "minimum version reported", "maximum version reported", and lastly "current issue/patch version", so actual work on the issue won't affect search queries.

A simple range would solve the database query/indexing issue, as it boils down to version_min >= :version_min AND version_max <= :version_max. The technical challenge would be to separately prepare + store release versions in a way that "puts them in natural order"; i.e., something along the lines of:

6.x-1.1 » 6101
6.x-1.1 » 6102
6.x-1.x-dev » 6199
7.x-2.3 » 7203

... and thus allows for chronological filtering of release versions.

People searching for issues would mainly use the min_version selector, in turn only leading to rid >= :version_min in the query. Obviously, also making the UI less of a challenge.

6.x-1.1 » 6102?? I'm sure you meant: 6.x-1.2 » 6102

Using 99 in the last 2 digits to denote dev releases is pretty smart, but what about alphas, betas & RCs?

Projects use the w.x-y.z[-dev/alpha#/beta#/rc#] format. I take it that core would simply be 622 (6.22), 699 (6.x-dev), 722 (7.22), 799 (7.x-dev) and 899 (8.x-dev). Right?

An extra column and min/max version sounds like a good compromise between UI and performance - would mean two select lists, but the extra one could default to the value of the first. It could get confusing for some, but no worse than people switching 8.x issues back to 6.x every few hours like they do now.

If you de-normalized the data, you could keep your indexed queries. In other words, the project_issues table should retain its current rid column, to reflect the highest selected version of the most recent project_issue_comment.

Of course, that means that searches would only match the version stored in the project_issues table, but that's how it works now, isn't it?

#1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it

Sorry; I thought the fact that we can't test patches against multiple versions in the same issue was the big problem. I had no idea people were complaining about lack of search options.

...we should revisit this some time after d.o runs on D7.

...reviving now that we are running D7.

meta issue - https://drupal.org/node/1080550

In #2455081: [policy, no patch] 8.1.x release schedule, we are moving toward a commit workflow that will involve issues being actively managed against as many as three minor branches at a time, with which multiple branches different issues are filed against communicating important information about the patch's place in the release schedule. The "needs backport to DN" issue tag workflow that we are currently using is challenging enough for just the major versions, but it will be completely infeasible for managing 8.0.x, 8.1.x, and 8.2.x together in a few months.

Therefore, I think we need to do the following:

1. Make version a multiple select field.
2. Move the issue tags out of the Version field into a separate optional "Release" field. This is already an overwhelming list from a usability perspective; it would be really impossible with that multiple select field.
3. Come up with a solution for automated testing for multiple branches.

We have a test definition format in YAML that a patch could change for the branch its applied to: #2295511: Architecture: DrupalCI Test definition format

We need to modify the test definition file to allow for tests against multiple branches.

We can't do that for the same reasons we can't do any of the other things: #2544340: Make the tests pass #2638466: Add a php container to make the codebase easier to test.

Re: #29 While these are both priority items, neither technically blocks moving forward with the work required here. What really blocks things is that the existing drupal.org integration was built with an assumption of a single simpletest job per patch, as was the case with PIFT/PIFR ... breaking that paradigm is the only technical requirement needed to unblock this, along with development of the associated UI mockups for triggering tests and associating test results to a particular core/project version.

I think that we need to move away from inheriting 'version' from the issue node, and instead add it as a field on the uploaded patch file. We can use the issue version to set the default value for this field, but the field should also allow the user to override this via a multi-select of one or more versions that they actually want the patch tested against. Extended File Field should already give us what we need to hide the version on the file table; and the alter hook approach used by PIFT to add test results to the file entries in the comment stream could be leveraged to add the 'tested against' version information to the comment after the fact.

Once the 'test against' version becomes a file parameter instead of an issue parameter, Drupal.org would then need to key off of this in determining which test job/jobs to pass on to the test runner ... which should not require a significantly difficult change to the existing logic.

Health permitting, I plan on spending some time this weekend in looking into how much of the field addition can be achieved through configuration on a dev site rather than code ... which might help us get to some functional mockups of what this might look like.

d.o is indeed using Solr for the issue queue views

Actually we're using Search API DB. So this will add a JOIN, but we did go and get a nice DB server in the last year or two.

#1171958: Allow files to be assigned to branch(es)/version(s) and thus tested against it is a prerequisite. We currently assume a file is for the issue's version. Getting that assumption cleared away will make this issue more doable.

Just to say there's a couple of things it'd be good to change in the project issue UI - I'm not sure if they're drupalorg or project issue issues:

- we could remove all of the tags from the version selector
- could also remove unsupported branches from the version selector
- useful for core (not sure about contrib) would be the ability to select a 8.x-minor or 8.x-patch as the version, rather than a specific branch, so that issues don't have to be updated every six months.

@catch filed #2691883: [policy, no patch] Branch labels for core for the third point of #33; we could also do separate issues for the first and second.

#2691889: Add option to remove tagged releases from the version selector and #2691895: Remove unsupported branches/releases from the version selector are those.

Moving back to project issue tracking, and active now that the other issue is in.

The main thing we're missing is:

- knowing which branches an issue is applicable against

- knowing which branches already have commits for that issue

knowing which branches already have commits for that issue

#443000: When viewing an issue, display a list of commits that reference that issue # has been around for some time, but we haven't enabled it on Drupal.org. It would add a sidebar block listing the commits in a branch, in addition to the comments added on commit. My thoughts were that would be redundant.

What sort of UI should we be striving for?

On short issues the block wouldn't add much, however where there's 100+ comments and discussion continues past the original commit, the commit comments tend to get lost.

For UI I'm not sure, what we're really missing is a way to look down a list of issues and see if it has commits - so almost a 'has commits' field, which could then be filtered on in the issue queue.