On 2015-02-15 2:05 AM, James HK wrote:
Hi,
I certainly don't want to drag this discussion but please let me clarify:
If I install mediawiki/semantic-media-wiki@2.0.1 today with composer, it will not tell me if it supports MediaWiki 1.16 nor will it tell me if it supports MediaWiki 1.26.
It is possible but the MediaWikiVersionFetcher in ComposerHookHandler is only loaded by Composer starting with MW 1.25 [0] allowing for such check to take place but since we need to support MW 1.19 we cannot not leverage on that.
When we introduced composer isn't really relevant, since I'm talking about the lack of information in relation to an extension's compatibility with MediaWiki in composer. Something that grows as we have more releases with composer support.
A hypothetical future example might be better than picking an old release number and one that doesn't exist.
We've had composer support for ages, the stable release is MW 1.42, there is a supported MW 1.40 LTS and a MW 1.36 LTS, and MW 1.43 is in development. Composer doesn't contain the information necessary to say: - If the latest version of mediawiki/semantic-media-wiki, 4.2.2, is compatible with the recent MW 1.40 LTS, or what the most recent release is compatible. - Same question, but for the MW 1.44 release that doesn't exist yet. Since the composer requires cannot be updated when MW 1.44 is released to say that 4.2.2 isn't compatible with it.
Ok maybe I should adjust that, since you could put a `mediawiki/mediawiki >= 1.39` by that point.
There are two problems: A) Even if you guys can put `mediawiki/mediawiki >= 1.39` in mediawiki/semantic-media-wiki. The average extension author will not bother to maintain a copy of the supported MW 1.44, MW 1.40 LTS, and MW 1.36 LTS to test their simple extension in, much less bother to find out that it supports `mediawiki/mediawiki >= 1.32`. B) It's impossible for you guys to know when you release 4.2.2, that MW 1.44 will introduce a breaking change that breaks 4.2.2 and you need to declare `mediawiki/mediawiki >= 1.39, < 1.44`.
The relationship between apps/libraries that use libraries, where semver works, is different from the relationship between Extensions and MediaWiki core.
In an app/library there's a fair chance that a new `2.0.0` of a library will break, so it's fine to depend on `^1.3.9` and wait till it's released to make any code changes you need to change to `^2.0.0`.
But for an Extension. MediaWiki is huge with piles of different components. Each release is almost guaranteed to include a breaking change. However most of these don't affect you and as long as you're not using a part that's currently getting a lot of attention for vast improvement (like skinning and extension management is now), your extension will likely work the exact same for the next half dozen releases (Sudo seems to have went at least from 2011-12 to 2013-10 without needing changes to keep compatibility with new releases). So you can't really declare that your extension can't use the next MW release when you don't know if it will or won't. Since then users wouldn't be able to install it as what MW release a user has installed is completely out of your control.
extension itself isn't published) automatically. Whether this is done by integration of composer/composer or packaging libraries automatically on the origin side.
- It should understand when it needs to take installation steps like
upgrading the database.
Yes, we are in agreement that an interface (including search, status update etc.) is necessary to make the user experience more pleasant for one or a bundle of extensions. I just don't want to see that dependency management suddenly becomes a trifle where the management of dependencies in itself is reinvented.
Ok, then lets break it down into smaller pieces of what is good and bad about using composer to manage extensions.
Some of the "bad" things I can think of about the composer direction: - Being forced to use composer names "author/name" when we already have a standard. - Being stuck using composer.json when extension.json is better matched with MediaWiki (things like i18n support for name/description, the same names we've been using forever and use in the extensions themselves). - Extensions being distributed and 100% dependent on a third party instead of distributed through MediaWiki.org. - Lack of support for alternatives to maintaining semver releases for smaller extensions. Such as just making every new batch of commits available to install. Or just maintaining a few REL#_## branches. (The latter two essentially how ExtensionDistributor works, but could still be nicer methods with more polish).
I guess there is merit to wanting to avoid reinventing (or reimplementing) dependency management. But likewise I don't want to shoehorn the entire MediaWiki extension ecosystem into the Composer library ecosystem to do so.
I wonder how accessible composer's dependency management code is. That is, whether it's possible to depend on composer/composer and use parts of its code not just for installing composer libraries, but also to implement dependency management in extension.json.
----
Btw, side thought. I wonder how the requirement to bump version numbers and make releases clashes with all the regular TWN message updates extensions get.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]