Remove EOL MediaWiki release branches
Closed, ResolvedPublic
Actions

Description

I'm not sure if this was intentional. In other projects one typically keeps release branches to tag new releases from, and then at some point the release is EOL and the branch can be removed (except for master).

These clobber the branch views in different places and are just annoying to deal with in CI. It'd be a lot easier and saner to work with if they aren't open to changes (technically) and would also enforce our social policies at a technical level.

Anything in these branches (all non-LTS, non-legacy branches: REL1_1 - REL1_18, REL1_20 - REL1_22) that is not released in a tag will never be released. And if for some extraordinary circumstances we decide to do another release, the branch is trivially re-created using the last tag from any release cycle.

Related Objects

Mentioned In: T190363: Restore lost git tags for older releases
T188084: Add Git tags REL1_XX for historical branches
T179754: Removal of EOL release branches broke SemanticMediaWiki CI
T113562: Create MediaWiki-Releasing project

Event Timeline

Krinkle created this task.Mar 12 2015, 3:41 PM

Krinkle raised the priority of this task from to Needs Triage.

Krinkle updated the task description. (Show Details)

Krinkle added a project: Release-Engineering-Team.

Krinkle subscribed.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 12 2015, 3:41 PM

greg triaged this task as Medium priority.Mar 12 2015, 4:10 PM

greg set Security to None.

Krenair subscribed.Mar 12 2015, 5:13 PM

PleaseStand subscribed.Mar 13 2015, 2:18 PM

Here's REL1_1/1.1.0:

chad@notsexy /a/vag/mediawiki (master)$ git log origin/REL1_1 ^1.1.0 --no-merges --oneline
aa3b6f6 Hide upload link if uploads are disabled.
3108d98 URL-encode main page link in CB
0c8f459 Applying some minor fixes from dev branch: * Strip whitespace from section titles in TOC * Slight tweak to HTTP redirects * Fixed sometime problem with linkcache inserting bad ID numbers * Don't blow up on #redirect to invalid title
a9a8023 Set $wgEnablePersistentLC to false by default; leads to SQL errors on MySQL 3.x installations.
c5a1c99 MSGNW in table fix from dev
1343c07 xml export missing
6ca3285 MediaWiki namespace
d39a4b8 Bulgarian translation from meta.wikipedia.org
e54783e Fix for bug #859195: the string '0' evaluates to false in PHP, even when using the empty() function, which can break links in the form [[foo|0]] such that the pipe text is ignored and the link title shows as the text
e70b344 Fix for bug #859195: the string '0' evaluates to false in PHP, even when using the empty() function, which can break links in the form [[foo|0]] such that the pipe text is ignored and the link title shows as the text
b502c51 Removed use of PHP persistent connections. Se URL below for details.
6a41de7 Article.php: * Made updating of page view stats faster my buffering them in a HEAP table until many pages can be updated at once.
651ccd8 Removed unused function wfUnbufferedQuery(). Added wfBufferSQLResults() to turn buffering on and off. Added wfIgnoreSQLErrors() to turn automatic error page generation on and off.
e4d0686 Added default text for when uploading is disabled. Since this is the default for new installations, it's important to have this text handy.
82bf050 IP substitution in blockedtext
824f536 bug fix in range block code, spelling error
4f8b5ea removed tracing printout
bdf73da The purpose of this modification is to ensure that every normal request execution starts and ends in wiki.phtml, giving the code a somewhat more predictable flow.
b8db4d6 Put the illegal char check down below again, to fix breakage to # links
ebed729 Put the illegal char check down below again, to fix breakage to # links
2cc982d Fix for #837969. Strict rejection of invalid characters in titles is good practice, and should keep away these problems with broken inaccessible pages created by page moves
4b628cc Update LanguageIt from dev after the install
20ea175 Fix for #837969. Strict rejection of invalid characters in titles is good practice, and should keep away these problems with broken inaccessible pages created by page moves
8dd9a2b Fix options
62c61cd Fix namespaces
a1cfc77 UTF-8
36b8346 (fix regression) Don't select the edit box on preview; this interferes with seeing what's going on.
fa63598 (fix regression) Don't select the edit box on preview; this interferes with seeing what's going on.
53fba65 Replaced calls to exit() with wfAbruptExit().
ea5c70a Added wfAbruptExit() function, to replace exit() calls with.
7ece699 Adjust whitespace
4ae0492 Fixes from dev branch: js error on non-edit edit pages, fix problems in mysql4 search
0302282 Only emit the javascript to set editbox focus when we're really editing
8b7d497 Fix parsing of multi-word expressions; by default behave more like google, with required match on all terms
9dda120 Made two new global variables for checking file extensions. The list of extensions is now configurable, and you can turn on and off file extension checking. There isn't yet a "hard" check, though.
7286862 Quote search text for regexp to avoid some errors with +foo etc
8af86cb proper CSS class for sitesupport link

And here's REL1_2/1.2.6:

chad@notsexy /a/vag/mediawiki (master)$ git log origin/REL1_2 ^1.2.6 --no-merges --oneline
3b47202 * (bug 1897) The native name for Javanese (jv) changed from "Bahasa Jawa" to "Basa Jawa".
9151118 * Changing the name for Sundanese (su) from "Bahasa Sunda" to "Basa Sunda"
85a8b79 Titles containing ./ declared invalid
c5fd8b8 Fix image deletion for file with ampsersand in name (bug 952546)
0e29ecf Back-port one line fix from 1.3 for encoding of prev/next links (bug 962017)
302201f fixed bug allowing invalid range blocks to be saved

So, people clearly hoped for further releases on these branches, but they didn't happen :)

I'm personally not opposed to cleaning them up.

I would keep legacy REL branches in the scm for multiple reasons:

historical purposes
the REL1_x branch names are referenced in a few places
I keep using git branch --contains to figure out in which major release a change got introduced in

In my experience, branches tends to stick around even after EOL.

greg added a project: MediaWiki-General.Sep 24 2015, 1:43 AM

greg moved this task from INBOX to Backlog (ARCHIVED) on the Release-Engineering-Team board.

greg mentioned this in T113562: Create MediaWiki-Releasing project.Sep 24 2015, 2:10 AM

Aklapper added a project: MediaWiki-Releasing.Sep 24 2015, 3:56 PM

@hashar: why wouldn't tags work for all of those purposes?

jayvdb subscribed.Apr 20 2016, 1:20 AM

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 20 2016, 1:20 AM

• mmodell moved this task from Backlog (ARCHIVED) to Long-Lived-Branches on the Release-Engineering-Team board.Jul 13 2016, 4:28 PM

• mmodell edited projects, added Release-Engineering-Team (Long-Lived-Branches); removed Release-Engineering-Team.

• mmodell moved this task from Backlog to Documentation + Loose Ends on the Release-Engineering-Team (Long-Lived-Branches) board.Jul 20 2016, 4:12 PM

In T92503#1772530, @mmodell wrote:

@hashar: why wouldn't tags work for all of those purposes?

Sorry missed your comment. Yeah a git tag REL_XXX would work I guess.

I'm actually less convinced this really helps anything, inclined to decline.

In T92503#2976462, @demon wrote:

I'm actually less convinced this really helps anything, inclined to decline.

I still believe that removing these branches would make MediaWiki code easier to browse in repo viewers, and easier to work with locally (in Git) by reducing noise of branches that clearly are not relevant as possible merge targets. It also makes it easy to find out which branches to use when trying to backport a change.

Right now one has to look up on https://www.mediawiki.org/wiki/Version_lifecycle which branches are "active". For example, right now we should only have master, REL1_28, REL1_27, and REL1_23. In the unlikely event that a closed release cycle gets a late minor release, the branch is easily re-created from the last tag.

I do agree however that if we remove them, we should properly remove them, and not convert to tags. As for potentially lost commits, these are presumably just un-released backports of commits already in master. Although I wouldn't oppose to converting the ones that have other commits to a tag for historical reasons (e.g. convert REL1_1 to tag "1.1.x").

I think we've spent more time discussing this than the problems we'll solve.

puts on release manager hat

Sorry, but I'm declining

Changed my mind.

• demon closed this task as Resolved.Nov 1 2017, 8:45 PM

• demon claimed this task.