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(a)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/]