Are you sure you are using the REL1_19 branch? https://github.com/wikimedia/mediawiki-extensions-Renameuser/tree/REL1_19

reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$ git checkout 9fea8b4ab306a786bef073c1b4802e4f155f581d
Note: checking out '9fea8b4ab306a786bef073c1b4802e4f155f581d'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 9fea8b4... Localisation updates for core and extension messages from translatewiki.net
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$ grep DIR *
reedy@ubuntu64-web-esxi:/var/www/wiki/mediawiki/extensions/Renameuser$

I went to https://www.mediawiki.org/wiki/Download and downloaded the 1.19.12 tarball:

$:andre\> pwd
/home/andre/mediawiki-1.19.12/extensions/Renameuser
$:andre\> grep DIR *
cleanupArchiveUserText.php: $IP = DIR . '/../..';
renameUserCleanup.php: $IP = DIR . '/../..';
Renameuser.php:$wgExtensionMessagesFiles['Renameuser'] = DIR . '/Renameuser.i18n.php';
Renameuser.php:$wgExtensionMessagesFiles['RenameuserAliases'] = DIR . '/Renameuser.alias.php';
Renameuser.php:$wgAutoloadClasses['RenameuserHooks'] = DIR . '/Renameuser.hooks.php';
Renameuser.php:$wgAutoloadClasses['RenameUserJob'] = DIR . '/RenameUserJob.php';
Renameuser.php:$wgAutoloadClasses['RenameuserLogFormatter'] = DIR . '/RenameuserLogFormatter.php';
Renameuser.php:$wgAutoloadClasses['RenameuserSQL'] = DIR . '/RenameuserSQL.php';
Renameuser.php:$wgAutoloadClasses['SpecialRenameuser'] = DIR . '/specials/SpecialRenameuser.php';
SpecialRenameuser.php:require_once( DIR . '/Renameuser.php' );
grep: specials: Is a directory

In that case I suspect it's time we double check that the release script doesn't boldly fetch master.

Even with a .0 release (e.g. 1.20.0) bundling master is a problem because when the bundle is made, it will have been X amount of time since the core branch and extension branches were created and more often than not, breaking changes are held back and land as soon as we branch, and then extensions are updated to work with it.

We ran into other bugs in the past when a 1.x.0 release was bundled with the then-latest-master versions of extensions (Cite, Vector, WikiEditor etc., released by Mark H. that time). This was a hurdle to deal with, and lead to all kinds of awkward bug reports on bugzilla and the support desk for many months to come that we couldn't really do much with.

Especially for later point releases it is very important not to fetch master since it will have been a long time since that release was originally branched from master.

Assuming that this was not fixed and we've been bundling master all this time for all releases, perhaps it's time to roll out a minor release back to 1.19.x fixing the extension versions back to where they should be?

Or at least for those extensions in those releases where we know things broke (e.g. 1.19 and Renameuser). And of course to fix the script (assuming it isn't done by hand, are these instructions documented somewhere) to do it right from now on.

I think it does fetch master, there's a bug about 1.22.3 release being broken in the way it's described here. Other releases are probably affected as well.

(In reply to Bartosz Dziewoński from comment #4)

I think it does fetch master, there's a bug about 1.22.3 release being
broken in the way it's described here. Other releases are probably affected
as well.

Sigh. So this is a bug in the tarball but not in the code repository of the extension... Workaround is to manually get the extension code from Git, I guess.

Closing as INVALID here for the code repository; tracking the problem with the tarballs in bug 62101.

Maxim: Thanks for catching this. :-/