The releases table in node/<nid>/edit/releases shows 6.x-1.03 as current release, not 6.x-1.1

I guess it's the expected result. 1.03 in 6.x-1.03 isn't a number with decimals, but it's two numbers separated by a dot: <major revision>.<patch level>. (It's explained in What do version numbers mean on contributed modules and themes?)

The code handling branch and tag names could probably be changed to not accept a tag like 6.x-1.03, but I am not sure implementing this change is worth the time took to write the code.

Let me give an example.

I have read_more installed on a site. I've just (past 2-3 days) started getting daily emails that one module / theme is out of date.

I have a look with Drush, and it's read_more. I have 7.x-1.1 installed, the latest version.
If I run drush dl, it gives me 7.x-1.01.

So I ignore the email telling me I have pending updates to install. Which is risky, because I may not notice when I genuine update is needed for another module, or indeed if read_more releases 7.x-1.2.

I'm adding this comment here as it seems to be the same issue as this one, but if this is something else requiring a new issue please let me know.

The ground for that issue is the same: A version like 7.x-1.01 is equivalent to 7.x-1.1 because 1.01 isn't a decimal number but two numbers separated by a dot.

For https://www.drupal.org/project/live_translation - The Git tags page, https://www.drupal.org/node/435814/edit/tags, visible to project maintainers only, was actually thrown together relatively quickly as part of Drupal.org’s repository migration to GitLab. At launch, GitLab did not make giving maintainers permission to delete tags possible; this has been fixed, https://gitlab.com/gitlab-org/gitlab-ce/issues/52954. I expect the Git tags page to be removed in the future, since we no longer have to work around the GitLab issue, and it would be a little less code to maintain.

Since the page was made quickly, and visible to maintainers only, it wasn’t sorted by anything in particular. The ordering of tags on https://www.drupal.org/node/435814/edit/tags is not related to anything else.

This is exactly correct:

A version like 7.x-1.01 is equivalent to 7.x-1.1

php > print version_compare('1.1', '1.01');
0

We should not allow this in the future. The current releases are made, so those issues will remain for any projects with this situation. I’d encourage project maintainers with this situation to make a definitely more-recent release, like 7.x-1.2 for https://www.drupal.org/project/read_more.

The validation to prevent future colliding releases like 7.x-1.01 / 7.x-1.1 is now in place.

Composer problem URL:
https://www.drupal.org/project/module_locator/releases/8.x-1.04
you see $ composer require 'drupal/module_locator:^1.4' instead of 1.04.

Drupal.org’s composer endpoint does version number normalization since contributed projects do not use semantic versioning. Both …:^1.4 and …:^1.04, and even …:^1.0004, all install “1.4.0”. So this is working as-designed.

There are only 22 cases of colliding version numbers on Drupal.org:

MariaDB [drupal]> SELECT group_concat(n.title), count(1) c FROM field_data_field_release_version fdf_rv INNER JOIN field_data_field_release_project fdf_rp ON fdf_rp.entity_id = fdf_rv.entity_id INNER JOIN node n ON n.nid = fdf_rp.entity_id AND n.status = 1 GROUP BY fdf_rp.field_release_project_target_id, regexp_replace(fdf_rv.field_release_version_value, '0+([0-9]+)', '\\1') HAVING c > 1 ORDER BY NULL;

• boost 6.x-1.01, 6.x-1.1
• pagination 6.x-1.01, 6.x-1.1
• live_translation 6.x-1.01, 6.x-1.1
• read_more 7.x-1.01, 7.x-1.1
• ecwid_shopping_cart 7.x-2.01, 7.x-2.1
• ecwid_shopping_cart 7.x-2.01-rc1, 7.x-2.1-rc1
• doubleclick 6.x-1.01, 6.x-1.1
• droptor 6.x-2.02, 6.x-2.2
• word_link 7.x-2.02, 7.x-2.2
• scald_file 7.x-1.01, 7.x-1.1
• wayback_filter 7.x-1.01, 7.x-1.1
• access_by_ref 8.x-1.01, 8.x-1.1
• link_icons 7.x-1.01, 7.x-1.1
• gesso 8.x-3.01, 8.x-3.1
• oa_comment 7.x-2.01, 7.x-2.1
• addressfield_lookup 7.x-2.01, 7.x-2.1
• glazed_free 7.x-2.51, 7.x-2.501
• designer 8.x-1.01, 8.x-1.1
• architect 8.x-1.01, 8.x-1.1
• new_custom_module 7.x-1.1, 7.x-01.01
• google_calendar_service 8.x-1.01, 8.x-1.1
• contact_default_fields_override 8.x-1.01, 8.x-1.1

Weird this. While I wait for the maintainers of read_more to release 7.x-1.2 to stop that module reporting itself out of date, I tried modifying my local read_more.info file to set the version number to 7.x-1.2.

Drush still shows this module as out of date. The Available Updates page (/admin/reports/updates/update) shows the installed version as 7.x-1.2, and the recommended version to be 7.x-1.01.

I can see why 7.x-1.01 could be suggested over 7.x-1.1. But why is 7.x-1.01 > 7.x-1.2?

Is there some other issue here?

/admin/reports/updates/update, and I expect drush too, use https://updates.drupal.org/release-history/read_more/7.x for data about what versions exist. Something like the release not existing is probably reported as out of date.

Thanks, yes of course.

So if I manually set the info field to 7.x-1.01 (which does exist), I no longer get prompted to upgrade the module, and when the real 7.x-1.2 comes out I won't miss it because the site thinks I already have that version.