Is it that you care about compatibility with your current version of MediaWiki? Or is it that you want to have the latest and greatest extension? If it's (only) the former, this bug has a different solution than if it's the latter.

In order words, why is the version number important to you?

olivier.beaton wrote:

I want the latest and greatest and unbuggyless. MediaWiki compat != extension bugfix releases.

wrt mediawiki compat, reguardless of compat issues with the extension moving into new versions of MediaWiki, as an administrator I can't DO anything about it until there is a new version of the extension. So even then the version is the correct tool for the administrator long term (short term compat charts let me disable extensions if I absolutely want to move mediawiki forward).

This is trying to fix a social problem with a technical solution. If we force every extension to have a version number, then I bet we will get several extensions that have all versions set as 1, which is worse than not having a version imo. (although perhaps some magic with svn keywords could be done to get the revision number even if not downloaded directly from svn)

I suppose we could try to add to the coding guidelines that people should add version numbers to their extensions, and update the version number as appropriate - but that should be discussed in a different forum (and personally I'm not entirely convinced that we should be doing that)

Anyhow, I suggest wontfix.

olivier.beaton wrote:

I should have been more clear, I didn't mean that mediawiki should refuse to run an extension that omitted the version number in the credits, this is counter-productive asfar as backwards-compat is concerned.

Merely that the extension docs should say you should specify it and keep it up to date (it doesn't even mention it). That Special:Version be changed to highlight the version number so not having one is more glarring and obvious.

I know in CVS people had auto-populated rev numbers in files, I don't have a problem with extension authors using this. We could add a 'revision' parameter which is auto-populated with the 'stable' (or whatever you checked out) revision number. Then if your 'version' field is blank, it could use the revision field instead.

The Extension infobox could state the trunk rev number for the extension if it's in SVN.

This way we would support 'version' and 'revision', without necesarily forcing people into SVN.

I should have been more clear, I didn't mean that mediawiki should refuse to
run an extension that omitted the version number in the credits, this is
counter-productive asfar as backwards-compat is concerned.

Merely that the extension docs should say you should specify it and keep it up
to date (it doesn't even mention it). That Special:Version be changed to
highlight the version number so not having one is more glarring and obvious.

That sounds much more reasonable then what I thought you were saying originally. :) I added version to the example in [[Manual:Developing_extensions]]

I'm leaving this open, because I'm unclear if you want other things done or changed.

;) Commit-id based version numbers will be fun when we switch to git *snicker*

(In reply to comment #5)

I should have been more clear, I didn't mean that mediawiki should refuse to
run an extension that omitted the version number in the credits, this is
counter-productive asfar as backwards-compat is concerned.

Merely that the extension docs should say you should specify it and keep it up
to date (it doesn't even mention it). That Special:Version be changed to
highlight the version number so not having one is more glarring and obvious.

That sounds much more reasonable then what I thought you were saying
originally. :) I added version to the example in
[[Manual:Developing_extensions]]

This. I've updated the bug summary from "mediawiki should require extension versions" to "MediaWiki should encourage extension versioning".

I'm leaving this open, because I'm unclear if you want other things done or
changed.

I'd say, at a minimum, all of Wikimedia's extensions (and possibly all "major" extensions) should use preferred form. A few docs should also be updated and then this can be closed.

(In reply to comment #6)

;) Commit-id based version numbers will be fun when we switch to git *snicker*

There's some way to get roughly equivalent functionality from Git. I don't remember if it's a truncated hash or it uses integers, but I know there's a hack that people have devised.

(In reply to comment #7)

(In reply to comment #6)

;) Commit-id based version numbers will be fun when we switch to git *snicker*

There's some way to get roughly equivalent functionality from Git. I don't
remember if it's a truncated hash or it uses integers, but I know there's a
hack that people have devised.

It's a truncated hash, and git understands that when you give it a partial hash it should try to find a hash that starts with it.

That doesn't change the fact that we move from sequential integer based revision numbers where r5 is always newer than r2. To a non-numeric commit hash which is non-ordered. So given AF456BC and BE98W9X there's no way to tell which is newer ;)

olivier.beaton wrote:

What about getting a 'version' column added to Special:Version? right now we add it in parenthesis after the name which is less than ideal and doesn't encourage it nearly enough in my books.

I use ~45 extensions and I don't have problems with their version number.

A version number won't fix bugs anyway, so why force it?

olivier.beaton wrote:

It's not that a version number will fix the bugs, but how do you know when an extension has a new version out? Do you use an spreadsheet to keep track of installed versions? a txt file? Do you keep all the .tar.gz files so you know what you installed last? But what do you do for the extensions that come from SVN, where the filename just has a mediawiki version (whatever is current) and a revision?

I'm not saying it's not doable, I currently use version numbers when available, and .tar.gz filename versions for others, and a handful I just upgrade regardless from svn just in the offchance there is a new version (usually when I do a mediawiki upgrade).

But I shouldn't have to do all that. It should be easy and friendly. I think displaying and more strongly encouraging extension versioning (by making it predominant and noticeable when missing on Special:Version) will go a long way to doing this.

Imho what we really need is a way to subscribe to updates on when something like an extension is changed.

SVN wise for awhile I've wanted to be able to define patterns of svn paths (ie: extensions, and some interfaces I care about) and even some regex pattern to catch changes in code I consider relevant and have e-mails sent to me on commit.

Larger extension wise people may not want alerts for every single commit though svn alerts are a start.

Besides the ability to subscribe alerts we also really need to embed branch and original Wikimedia rev info when an extension is downloaded or checked out. And we need an easy way to query a Wikimedia api to see if the revs or versions have changed.

Version numbers, update alerts. I don't believe either of those are really effective at all at letting users know when to update in other software. In WordPress at least I'm quote sure that the most effective way users are kept up to date is WordPress' plugins page listing plugins that have been updated since the the version you have was released. And such a thing has little to do with encouraging every single extension to publish version numbers. For a small extension where just about every new rev is a fully functioning release with very minor changes which are really fixing small bugs and code style tweaks there is practically no advantage to defining a version number over just using rev ids to know when an extension should be updated.
However note that WordPress also combines this with a community of users commenting on the compatibility of an extension with a version of WordPress.
We also have avoided this kind of thing for awhile because the act of indiscriminately making http calls out of the box has a number of implications in security, performance, and privacy. It also has other issues with some hosts restricting the ability to make outbound http requests. And also requires that Wikimedia keeps some service running indefinitely that piles of MediaWiki installs will be making calls to.
The first thing we'll probably need is a service that actually tracks revs, published version numbers, branches, and versions of MediaWiki. From there the simplest thing to start with would be a Special:Version feature that has a link called something like "Check for extension updates" which would be a link to the service containing an encoded set of the current MediaWiki version, what extensions are installed, what branches those extensions came from, their Wikimedia revision ids, and any published version numbers. Then the service would use that voluntarily submitted information and compare it to the current status of those extensions and inform the user if there are any updates.
After that we would consider expanding it into a full api and adding some way of having MediaWiki make the calls itself.
That said, I don't know how nice the idea of changing "This wiki has version <x> of extension" to "This wiki has version <x> of extension, the latest version of <y>, you should update this extension." when in our case just about anyone looks at Special:Version for various purposes. And unlike WordPress we don't really have any special dashboard primarily used by the people that have the ability to update the install.

Later on we may want to consider things like letting extensions give a custom definition of places to look for updates.

olivier.beaton wrote:

Hi Daniel, none of that is new I'm sure to people in the community. But it really bares repeating.

In terms of control panel we are making slow progress with:
http://www.mediawiki.org/wiki/Extension:Maintenance
http://www.mediawiki.org/wiki/Extension:Admin_Links
http://www.mediawiki.org/wiki/Configure
and the missing part of course is Special:Version.

All of these leave a lot to be desired, and while some may disagree, I believe wordpress is the right direction. We don't need to core-ify any of these until they are mature however and it's a clear win all around.

I'm glad you brought this up Daniel, because I have an extension sitting here in my editor called 'ExtensionUpdate'. If I had commit rights it would be checked in right now, although it's not ready for testing yet (give me a few more days).

I fully plan to tackle the problem of trying to provide a 'there is a new version of this extension out'. Eventually it will tackle 'let me download that' to 'let me unpack and install that'. Maybe even oneday it will do so for the core.

But before I can start checking if there is a new version, I need version numbers to be more prominent. Hence my request here. If oneday an extension core'ified and becomes the new Special:Version page great. We don't need to revolutionize it right now, people can make extensions and fight it out.

But the default core needs to encourage people to put in version number as much as possible, and making it more prominent in Special:Version is a minimal change that I believe would go a long way (why is that box empty, ack!). A loner extension won't get that kind of push.

Like I mentioned, putting the revision automatically on checkout into a 'revision' field in $wgExtensionCredits would also be great, and publishing it on the extension pages. But like others have mentioned this won't for git, so to be safe should we really rely on a comit revision system? Maybe just stick with version numbers for now and authors can decide when it warrants to be pushed out to everyone.

You can bet that new API calls is next on my list, but at least with version numbers we make administrator's lives easier everywhere, they can do the comparison by hand for now.

olivier.beaton wrote:

23:45 < bawolff> I was thinking another approach to that version bug, would be

for ExtensionDistributor to annotate extensions downloaded
from it with revision number some way (like via a hidden file)
that MW could read and understand

This is really interesting. A hidden file with revision information sounds great. Knowing if it was 'trunk' or what 'branch' would be great too. This way we don't need to rely on extension authors to add an auto-gen var to one of their files, since we can add the hidden file automatically to any extension branch before we check it out and have it auto-populate.

Something like Special:Update can then read out the info, and use API calls to determine if the extensions need updating.

When we move to GIT we simply change from revisions to hashes and use the API to know if my hash is older than the one MW has.

This also alleviates the need for extension authors to update their versions and de-values the version numbers quiete a lot.

As an admin and extension author I still like versions, but this would go a long way to making them seem 'old-school'. (what version of chrome do I have? I don't really care).

"It's not that a version number will fix the bugs, but how do you know when an
extension has a new version out?"

I use the watchlist which comes with more advantages besides being notified about new versions immediatly.

How do you (want to) do? Click all links on Special:Version to compare on mediawiki.org if a new version is available? Not very comfortable either!

olivier.beaton wrote:

That's an interesting point Subfader, and I can't believe I've never used it for that before.

However that only works if the extension author... updates their version. Otherwise nothing ever changes on their extension page (ala Cite). This is making SVN revisions (or git hashes) look more attractive by the second.

I think I may open a different bug for that, and if it's determined that people are unwiling to modify Special:Version, I think this is as far as versions will ever get.

My work on Extension:Update is continuing, and it will support versions at first, then I'll push for support for revisions elsewhere and extra API calls.

Thank you for all the feedback.

I tend to agree that 'version numbers' here only really make sense in the context of an install-and-update channel.

A human-invented version number stuffed into the 'extension info' for instance would add very little as it's likely to not get updated regularly; and you have nothing to compare it against other than wandering around to SVN and checking what the current value in trunk is, meaning it adds little or nothing over just pulling updates from SVN to begin with.

Rather than relying on some manually-updated variable in the code, this should probably be based on release pushes of some sort.

olivier.beaton wrote:

Ok, I think encouraging it in the Manual: was a good addition, IMO authors should version, but you're right that pushing it harder in Special:Version is not the right tact, Special:Update using SVN revisions or GIT hashes will be more powerful. Since I'm already requesting exposing SVN revisions in https://bugzilla.wikimedia.org/show_bug.cgi?id=30970 I'll mark this bug as resolved (improved documentation). Thanks for the discussion people!

olivier.beaton wrote:

I thought people here may be interested to know that Version 0.1 of Special:Update has been released. Please let me know if you encounter any problems.

http://www.mediawiki.org/wiki/Extension:Update

It will notify you when new versions of MediaWiki stable or the version number on the extensions you have installed from MW pages updates.

Other plans to come!