Page MenuHomePhabricator

Add Git tags REL1_XX for historical branches
Open, Needs TriagePublic


I am updating an old wiki in 1.20 and set up a dev environment to prepare the update, and my git clone -b REL1_20 returned an error, relatedly to T92503.

I aggree with the spirit of T92503 (remove old branches), but it could be created Git tags named REL1_XX to keep compatibility with the old behaviour: git clone -b REL1_20 would work.

Even if old versions are not supposed to be used in normal temperature and pressure, such tags could help to smooth transitions from active branches to historical "branches". Without it, it would be more difficult to get the last minor version of some branch: you have to git-clone the whole repository, list the tags, find the latest tag in the branch, and git-checkout this tag.

This solution was evoked in T179754, this task is dedicated to this and not directly linked to SemanticMediaWiki’s CI.

Event Timeline

Seb35 created this task.Feb 23 2018, 10:40 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 23 2018, 10:40 AM

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'.

demon added a comment.May 15 2018, 7:37 PM

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.

demon added a comment.May 19 2018, 1:34 PM

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).

Seb35 added a comment.Nov 24 2018, 1:13 PM

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 to ensure all links are updated to point to the relevant tag, instead.

Kghbln added a subscriber: Kghbln.Jun 13 2019, 7:51 AM
Wladek92 added a subscriber: Wladek92.EditedJun 17 2019, 11:00 AM

In mediawiki I speak of similar problem (see ) .
Nevertheless (?palliative) I can access to release note of version 1.18 using
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 :