As mentioned in T190363, this is also really important for extension writers who want to support more than the current latest-and-greatest versions of MediaWiki. We need to have an easy way to locate old releases in order to check whether a given feature we would like to use was supported.

With the appropriate tags, it is very easy to find the revision where a feature was introduced and then have git list the tags that include that commit.

Without the tags, you have to download each of the source tarballs and browse them in turn in order to find out whether or not the relevant feature is available in that revision (which is made even harder due to the issue raised in T190369). It also makes testing against different versions a lot harder than a simple 'git checkout'.

I do want to raise a point about a lot of these branches. For example....what good does REL1_26 as a tag do?

$ git log origin/REL1_26..1.26.4 
$ git log 1.26.4..origin/REL1_26

There's no difference....

Also, you mention old "releases" specifically. They've all been tagged and remain tagged. Commits in a release branch beyond the last tag aren't in a release (and if they're EOL never will be).

I'd like to rephrase my prior comment... What are you looking for in a REL1_xx branch that's not in a tag? Can you point to examples where such a commit breaks an extension?

you have to git-clone the whole repository, list the tags, find the latest tag in the branch, and git-checkout this tag.

Couldn't git ls-remote... get you this info?

Just tried on my phone which definitely doesn't have MediaWiki cloned :)

I think the motivation of this task was that when the REL1_XX branches were deleted because they're old, to replace them with tags, so CI or other tools that checkout REL1_XX will continue to work without needing any modification.

I think CI tools should be a little smarter then and work from tags for now-discontinued branches (really, they shouldn't care about EOL'd branches at all, but that's certainly nothing new).

We should really advertise this data programatically. Resurrecting my MWReleases extension (or doing something similar) would aid folks here, as well as simplify the release process (cf: mw:Module:Version).

I didn’t know git-ls-remote, that helps a bit, but from a programmatic (or mental for humans) point of view you still have to implement some logic to:

1. git ls-remote
2. remove various stuff like "rc" and "beta"
3. grep your searched version (e.g. 1.20)
4. sort the versions
5. take the last entry, but if the last entry ends with ^{} you have to take the entry just before, which should be the same without the ^{}

So, yes, it is possible, but it’s a lot more work than retrieving a REL1_XX branch or tag, particularly easy given git clone -b REL1_XX choose either depending on what is available.

The real advantage of REL1_XX is the uniform name to get "the last version in the 1.XX serie", be it for humans or for tools. For humans, the fact is there are so much old MW out there that it is frequently needed to navigate accross MW versions, for instance to test what was the last version that a custom or old extension supports (and there a lot of old unmaintained extensions, some of which with interesting features) or what was the minimum MW version an extension supports for documentation purposes. Although there are other means, this would be a small aid to facilitate in this task.

From my perspective, tags are fine.

The thing I want to be able to do is to easily find the revision that represents any MediaWiki release in the git history, and then either browse that code-base or perform diffs between that commit and any other arbitrary commit. I am less interested in a general REL_1.7 tag than the specific REL_1.7.0, REL_1.7.1, etc. I am not interested in unreleased changes.

I don't know whether it makes a difference to other use-cases, but that's the situation for mine.

Your screenshot implies that the tags are already there, which is odd as I couldn't find them when I was originally logged T190363. Have they been added since then, or was I just looking in the wrong place?

Further to my above comment, about my personal use-case, I have found that there are public links - even from prominent pages on mediawiki,org - that are currently dead.

For example, most of the Git links for old revisions on the Release notes page are broken. This is not the only place.

I would be in favour of reinstating the missing branches in order to fix the broken links, but if not there should at the very least be a full search of mw.org to ensure all links are updated to point to the relevant tag, instead.

In mediawiki I speak of similar problem (see https://www.mediawiki.org/w/index.php?title=Topic:V1r4zru368o47cb9&topic_showPostId=v1r4zru36cm6fg9h#flow-post-v1r4zru36cm6fg9h ) .
Nevertheless (?palliative) I can access to release note of version 1.18 using
https://www.mediawiki.org/wiki/Template:RELEASE-NOTES
You can link to a specific release notes file via {{RELEASE-NOTES|version}}, e.g. {{RELEASE-NOTES|MediaWiki 1.31}}
All release notes seem accessible under :
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+refs