Recently I have noticed quite a few issues switch version, like this:

Version: 7.69 » 10.0.x-dev

Example

It seems like the issue Version selector has been slimmed down, so it's not possible to select for example 7.71 but only 7.x-dev. Is this on purpose?

Comments

ressa created an issue. See original summary.

drumm’s picture

Project: Drupal.org customizations » Drupal core
Version: 7.x-3.x-dev » 9.1.x-dev
Component: User interface » other
Status: Active » Closed (works as designed)

#2691889: Add option to remove tagged releases from the version selector is the issue where this change was made. It is an option for each project’s maintainers to decide.

There was some gap between when this configuration change was made by core maintainers and #2847734: Bulk update core issues from tagged releases to dev versions. Issues updated before that update would have defaulted to the first version option, 10.0.x-dev, and be saved that way if they didn’t catch the change.

ressa’s picture

Thanks, but I think it is mostly a challenge with Drupal issues, not so much modules, they seem fine, and still include detailed version. Or would this start happening, if module maintainers decide to use this limited format?

I think it is pretty useful to be able to see if an issue is filed against 7.10 or 7.69, like in the issue I linked to as an example, 7.x-dev could be any of those. I take it has been actively decided to use 7.x-dev, rather than for example 7.10 in the Drupal issue queue under drupal.org/project/drupal/issues, I linked to as an example?

Also, like @dww comments, which I agree with, using 7.x-dev seems counter-intuitive:

People shouldn't be searching for issues via 8.x-1.x-dev, they should be using "8.x issues".

The Version list in the search form at https://www.drupal.org/project/issues/drupal seems to have duplicates ... or I am not sure if I understand the difference between All 10.0.* and 10.0.x-dev. Aren't they the same?

  • - Any -
  • - Any 10.* -
  • - Any 9.* -
  • - Any 8.* -
  • - Any 7.* -
  • - Any 6.* -
  • - Any 5.* -
  • - Any 4.* -
  • All 10.0.*
  • All 9.1.*
  • All 9.0.*
  • All 8.9.*
  • All 8.8.*
  • All 8.7.*
  • All 8.6.*
  • All 8.5.*
  • All 8.4.*
  • All 8.3.*
  • All 8.2.*
  • All 8.1.*
  • All 8.0.*
  • All 7.*
  • All 6.*
  • All 5.*
  • All 4.7.*
  • All 4.6.*
  • 10.0.x-dev
  • 9.1.x-dev
  • 9.0.x-dev
  • 8.9.x-dev
  • 8.8.x-dev
  • 8.7.x-dev
  • 8.6.x-dev
  • 8.5.x-dev
  • 8.4.x-dev
  • 8.3.x-dev
  • 8.2.x-dev
  • 8.1.x-dev
  • 8.0.x-dev
  • 7.x-dev
  • 6.x-dev
  • 5.x-dev
  • 4.7.x-dev
  • 4.6.x-dev
drumm’s picture

Or would this start happening, if module maintainers decide to use this limited format?

Every project maintainer has the option to not offer the tagged release versions as options. It is up to maintainers of each project to decide.

difference between All 10.0.* and 10.0.x-dev. Aren't they the same?

Right now, they are effectively the same. When 10.1.x-dev is created, it won’t be included in All 10.0.*.

ressa’s picture

Thanks for clarifying. I am still not entirely sure I get the distinction ... so perhaps 10.0.x-dev in the search form is the actual dev-release, and only ever a single entity, whereas All 10.0.* includes 10.0.1, 10.0.2, etc.? I think also having 10.0.x-dev meaning every version 10 release in the issue form Version field (here) throws me off. I might just need to use it, to understand it.

drumm’s picture

Yep, that's true. 10.0.x-dev is an exact match for the dev branch release. All 10.0.* includes all 10.0.* releases, if they are offered as options.