I have already asked as for why before. This question was being ignored so far. As far as I am concerned we should link to Diffusion until somebody has the mercy and convenes to provide rationale to us beggars for not doing so.

Thanks a lot for the info. I guess the original intent of the question was to get a sane gui for looking at code and not for doing code changes. So a valid reason for not pointing to Diffusion is that it will be shut down also for code display. I am not sure if Gitlies is best of breed.

I would like also a decent web viewer for code (and not code changes) and ultimately with a stable URL, e.g. to link from tasks to some specific lines of code and ultimately be able to read the same thing 10 years after.

Here the original request was to add a link to Diffusion (that) and not Differential. I do prefer Diffusion over Gitiles, even if I recently found there is the possibility to display by clicking on the branch 'master' (that).

Meh, writing e.g. "GPL-2.0-or-later" instead of "GPL-2.0+" is not really an improvement besides making the obvious even more obvious. Do we want to change the string users have to add to the template or do we just change the module to display a different label for the same license?

Unfortunately, I've come across enough places where people just put GPL-2.0 when in reality it was -or-later. Hopefully this will fix that. I think in the beginning we should just change the text and accept both forms of the license, and once 3.0 becomes more widely used we can start updating existing pages to use the new version?

Sounds reasonable to me to do it like this. In the end it will be an extension by extension effort to check and amend the information. I am not sure if this change will provide an improvement since a lot of people just write GPL. Still there is hope for better awareness now. Moreover in case of uncertainty GPL-2.0 it is better to be added than GPL-2.0+, but that's another story.

I’m also enclined to be against such a change, at least in the current presentation of the infobox: I find there are already too much things in this infobox and it is already difficult to read. I find a general re-organisation of the whole infobox would be very welcome, perhaps removing some links and/or using pictograms for some links.

A step further about what Tacsipacsi suggests, perhaps a template Contribute could be created and transcluded in the page, something like Template:ExtensionInstall does for installation.

no headings for readme and changelog, the whole "Download" section.

In Extension:PieceOfCode I gave the readme parameter a value, but it just appears as an unidentified link under Download. I assume the same is true for changelog. The easy fix would be to provide link text for each, same as "Browse source code"

But with all these links, you're not downloading anything., so none belong under a Download column! They're just links to files that probably reflect the latest code, and the infobox seems to conflate this with "snapshot". It seems there should be a separate infobox section for Project, with links in it for browse source, view changes, readme, and changelog.

what should mediawiki parameter represent?

but is this the earliest version of MediaWiki for which there's a branch of the extension, or the earliest version of MediaWiki on which the extension's latest master will work?

There seems to be consensus that instead of the "master" branch supporting old MediaWiki releases, developers on releases should use the version of the extension tagged for that release from Special:ExtensionDistributor.

Note that even users running MediaWiki 1.25 should download the version tagged for that, because incompatibilities may happen if the extension was adapted to use new features introduced on master. This warning should probably be on the Special:ExtensionDistributor page

The way I currently handle it is that I archive extensions listed in Category:Obsolete extensions after there is not supported version of MW around which may be used together with the respective extension. So the information provided with the obsolete template is not really best fit. No objections having this status since we already have "unmaintained".

Hi, having this parameter was a very good idea. However I suggest to remove the explanation "php update.php needed after installation" from display. I takes heaps of space. I think everyone may just click on the link which takes one directly to the documentation of the parameter and its implications. Cheers