Last week, I spoke to a few of my Wikimedia Foundation colleagues about how
we deploy code—I completely botched it.
At the end of the conversation, I was pretty sure I'd only succeeded in
making a complex process more opaque. I decided to write a blog to redeem
myself: How We Deploy Code
My goal was to write a very high-level overview of the process we use to
deploy code to Wikimedia production.
Hopefully, this is helpful.
– Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
I'm confused about what the term "ltsrel" means. The way I understand it,
it *should* mean that the extension supports only Long Term Support
versions of MediaWiki. It would have a branch for every LTS version of
MediaWiki like REL1_31 and REL1_35, but not for REL1_32, REL1_33 or REL1_34.
However, on the Compatibility
the rel and ltsrel policies are described as:
* release branches (key: rel): For every MediaWiki release, there is a
corresponding branch in the extension. So e.g. if you use MediaWiki 1.36,
you should use the REL1_36 branch of the extension.
* long-term support release branches (key: ltsrel): For every MediaWiki
release, there is a corresponding branch in the extension, following the
Version lifecycle release policy.
These sound exactly alike to me.
version of Parsoid) is also EOL starting today.
in 2019 and the PHP port is now part of all MediaWiki releases. With the
EOL of the MediaWiki 1.31 LTS, LTS support transfers to Parsoid/PHP
0.12, which was included as part of the MediaWiki 1.35 LTS distribution.
Parsoid/JS has only been receiving security releases since 2020 and will
no longer get any security updates. We recommend all Parsoid users
switch over to Parsoid/PHP.
on behalf of the Content Transform Team (formerly the “Parsing Team”)
This release includes Node.js 12 and npm 7.
Get started by installing, updating, or learning more, at:
This release upgrades the default "fresh-node" command to the latest WMF CI
image for Node.js, which bundles Node.js 12 and npm 7. It is based on
Debian 11 ("Bullseye") and includes Firefox 78 and Chromium 90 as well.
The previous Node.js 10 environment remains available as "fresh-node10" in
case you need it during the transition over the coming weeks. It will
likely be removed within a month or two. If you encounter problems with
Node.js 12, let us know on Phabricator! 
This release also introduces a "fresh-node14" command for experimention
with Node.js 14.
Fresh is a fast way to create isolated environments from your terminal.
These can be used to more securely work with 'npm' developer tools such as
ESLint, QUnit, Grunt, Selenium, and more. Example guide:
As per the MediaWiki version lifecycle, I would like to announce the
formal end of life (EOL) of MediaWiki 1.31 as of tomorrow, Thursday
September 30, 2021, coinciding with the final security and maintenance
release for the branch, 1.31.16.
This means that MediaWiki 1.31 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade to MediaWiki 1.35, the current Long Term
Support (LTS) version which is not due to become EOL until September 2023.
MediaWiki 1.35 bumps the required PHP version from 7.0 in 1.31 (which is
unsupported upstream), to PHP 7.3.19 or later.
Tomorrow we will be issuing a security and maintenance release to all
supported branches of MediaWiki.
The new releases will be:
This will resolve 3 issues in MediaWiki core and also includes some fixes
previously committed to git, including minor security and hardening patches
along with bug fixes included for maintenance reasons.
It also fixes 1 issue in a MediaWiki tarball bundled extension.
We will make the fixes available in these respective release branches,
master and the currently unreleased 1.37 branch. Tarballs will be available
for the above mentioned point releases as well.
A summary of some of the security fixes that have gone into non-bundled
MediaWiki extensions will also follow.
As a reminder, 1.31 (the old LTS) was due to become end of life (EOL) in
June 2021. 1.35 (the new LTS) is supported until September 2023. However,
to try and meet our LTS-LTS overlap commitments (1.35 was late due to
COVID), 1.31 got best-efforts extra support until the end of September 2021.
As the end of September 2021 is now upon us, this means 1.31.16 will be the
final security (and maintenance) release, and therefore it is considered
EOL as of tomorrow, September 30, 2021.
The small group working to develop a peer exchange platform
<https://meta.wikimedia.org/wiki/The_Capacity_Exchange> for Wikimedians
needs some help with software development. We are looking for someone who
can do the installation and adaptation work of an existing java-based site
under a freelance contract. Details are described here
If you or someone you know could do this work please contact us.
Senior Advisor Global Partnerships
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-32
Mobile (0151) 50824711
Unsere Vision ist eine Welt, in der alle Menschen am Wissen der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
Bleiben Sie auf dem neuesten Stand! Aktuelle Nachrichten und spannende
Geschichten rund um Wikimedia, Wikipedia und Freies Wissen im Newsletter: Zur
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
A quick note that, after discussion on T288392, we've reconfigured
gitlab.wikimedia.org to use shell names for users instead of the LDAP
CN, and renamed all existing logins to match. This seems like a better
match for most users' expectations, and better ergonomics overall.
As a quick example, I was BrennenBearnes before, and now am at:
GitLab handles redirects for renamed users both in the web interface and
for git remotes, but if you want to reconfigure the remote URL for an
existing clone of a repo, you can do something like the following,
substituting your new username:
$ git remote set-url origin email@example.com:brennen/test.git