@Samwilson Do you think this is a GraphViz or and SemanticResultFormat issue. In case of the latter this issue belongs to GitHub issue tracker for SemanticResultFormats. Anyways if you know how to fix this that will be cool since I believe a lot of people use this extension combo to get most out of GraphViz.

I'm afraid I'm having trouble getting SemanticResultFormats set up locally (running into this), so haven't replicated this yet.

I believe you have discovered the root of the issue. SRF can only be installed using Composer. That's just the way it is until MW is able to handle PSR-4 (cannot find the task right now). So if you install SRF one currently cannot use GraphViz 3.0.0+ via the SRF formats making use of it. That is what this issue is about I believe.

Yes, good point. Hmm. It's a tricky one. The SRF devs seem dead against supporting extension registration, and want to remain installable only with Composer. I *think* it might be possible to copy parts of the require and autoload bits of SRF's composer.json into composer.local.json and maybe it'd work? Not sure. Anyway, it's quite at odds to how pretty much all other extensions are done. :-(

Anyway, it's quite at odds to how pretty much all other extensions are done. :-(

SRF doing so is much older than the invention of extension registration. I am sure SRF will go this way as soon as PSR-4 (T173799) is implemented.

The SRF devs seem dead against supporting extension registration

The extension registration has nothing do with whether you use Composer or not.

... and want to remain installable only with Composer.

Please don't make it sound like we are the bad guys, SRF has been working with Composer long before extension registration was invented and does so after it. The tests and Travis do work just fine and in regards to the linked issue, it has outlined requirements as to when we expect to support the extension registration.

The installation instructions are clear and concise and have nothing to do with whether one uses the extension registration or not, which in case you would, would only influence the activation point and not how you install the extension.

If user require a tarball release, then the community is free to provide such service but developers have hardly the time or capacity to provide those that work just fine by relying on Composer.

GraphViz no longer working ...

In regards to "GraphViz no longer working ...", GraphViz was working relatively fine with version 2.x, now with 3.x it stopped working and the only conclusion is that since SRF hasn't changed anything in regards of how it uses GraphViz recent changes to GraphViz most likely introduced a regression.

@mwjames, you're completely correct, the fault here does not lie with SRF, and I really didn't mean to imply that you are doing anything less than a stellar job with that extension. I'm sorry that I came across as rude.

The changes that I suggest are required are in this pull request: https://github.com/SemanticMediaWiki/SemanticResultFormats/pull/365

Basically, GraphViz has a new class structure, and it's not backwards compatible (hence the major version update).

Also, the trouble with SRF's Composer usage is just that it adds mediawiki/semantic-media-wiki as a requirement, and so differs from most other extensions in that one can't simply clone it (and SemanticMediaWiki) into extensions/ and add the required lines to composer.local.json. This doesn't matter in the normal Composer-based installation situation, but is a slight hiccup for some setups (e.g. in development).

In T181926#3880452, @Kghbln wrote:

Imho it was a bad idea to introduce manifest 2 with MW 1.29 rather than MW 1.31. Not having aligned something like this with LTS releases of MW leads to something that we can see in the above compatibility overview. However, that's probably another story.

This is very true, and I'm sorry I instigated this. I think I was initially thinking it didn't matter as there were other non-backwards-compatible changes that needed to be made, but that's not right so we needn't have made the change. Oh well, live and learn I guess! I wish Jenkins ran tests on all current versions of MediaWiki.

In T181926#3881046, @Samwilson wrote:

In T181926#3880452, @Kghbln wrote:

Imho it was a bad idea to introduce manifest 2 with MW 1.29 rather than MW 1.31. Not having aligned something like this with LTS releases of MW leads to something that we can see in the above compatibility overview. However, that's probably another story.

This is very true, and I'm sorry I instigated this. I think I was initially thinking it didn't matter as there were other non-backwards-compatible changes that needed to be made, but that's not right so we needn't have made the change. Oh well, live and learn I guess! I wish Jenkins ran tests on all current versions of MediaWiki.

My "rant" was actually not directed towards you. If it is there I cannot blame people to use it. In the meantime there are several extensions I cannot longer update due to this "premature" introduction into MediaWiki core. I meant it should not have been effective prior to MW 1.31 at all so indeed this task is not the right forum for this.

In T181926#3880452, @Kghbln wrote:

Imho it was a bad idea to introduce manifest 2 with MW 1.29 rather than MW 1.31. Not having aligned something like this with LTS releases of MW leads to something that we can see in the above compatibility overview. However, that's probably another story.

The main advantage of introducing it in 1.29, was so that by the time it reached 1.31 it would be fully stable/documented and have any bugs wrangled out. I actually tried to have it land in 1.28, but we ended up reverting the entire thing out of REL1_28 because it wasn't ready yet. (Coincidentally this also matches the introduction of extension.json itself in 1.25, two releases ahead of the LTS, in 1.27.)

In T181926#3881704, @Kghbln wrote:

My "rant" was actually not directed towards you. If it is there I cannot blame people to use it. In the meantime there are several extensions I cannot longer update due to this "premature" introduction into MediaWiki core. I meant it should not have been effective prior to MW 1.31 at all so indeed this task is not the right forum for this.

Multiple times I (and others) have said that there is no point in upgrading to v2 unless there is some feature in v2 that you need (very few extensions according to my audits). If extension maintainers are using it without realizing the consequences..tell them? And if you have suggestions on how to improve extension.json's compatibility, please let me know instead of ranting on random tickets (it's mostly coincidence that I saw this on IRC).

please let me know instead of ranting on random tickets (it's mostly coincidence that I saw this on IRC).

Coincidentally, I saw your comment and since I'm somehow subscript to it, I'll have to object to your claim of randomness. While the discussion may have been a bit broader in terms of the previous stated issue it is still a valid comment in terms how a feature in extension.json makes it usefulness for a other dependent software less than ideal. I think a member of this community (in this case Kghbln) should have the opportunity to articulate such opinion, or is not longer appreciated?

If it is not recommended to use manifest version 2 unless actually required, that should be communicated on https://www.mediawiki.org/wiki/Manual:Extension_registration . At the moment, I'd say it's pretty natural for developers to just go with whatever the highest version is, rather than purposefully writing new code against and old API. At least, that was my take on it, which got us into the current confusion! :-)

Of course, there's always the balance between using new features in order that their bugs be ironed out, and not using them until those bugs are ironed out!

In T181926#3881726, @mwjames wrote:

please let me know instead of ranting on random tickets (it's mostly coincidence that I saw this on IRC).

Coincidentally, I saw your comment and since I'm somehow subscript to it, I'll have to object to your claim of randomness. While the discussion may have been a bit broader in terms of the previous stated issue it is still a valid comment in terms how a feature in extension.json makes it usefulness for a other dependent software less than ideal.

Well yes. But his comment (as I read it) was aimed at the extension.json maintainers, aka me, and this is the wrong venue for that (even Kghbln themselves said that). From my perspective, this is just a random ticket, I happened to see on IRC.

I think a member of this community (in this case Kghbln) should have the opportunity to articulate such opinion, or is not longer appreciated?

Somehow you must have accidentally missed the part where I said "please let me know", which implied that I do appreciate their opinion. I would please ask that you don't try and put words in my mouth.

In T181926#3881728, @Samwilson wrote:

If it is not recommended to use manifest version 2 unless actually required, that should be communicated on https://www.mediawiki.org/wiki/Manual:Extension_registration . At the moment, I'd say it's pretty natural for developers to just go with whatever the highest version is, rather than purposefully writing new code against and old API. At least, that was my take on it, which got us into the current confusion! :-)

I updated https://www.mediawiki.org/w/index.php?title=Manual%3AExtension.json%2FSchema&type=revision&diff=2683857&oldid=2644521. https://www.mediawiki.org/wiki/Manual:Extension_registration has become a collection of a bunch of different things that I need to clean up - I'll try and do that over the next few days.

Of course, there's always the balance between using new features in order that their bugs be ironed out, and not using them until those bugs are ironed out!

Indeed. :-)

I would please ask that you don't try and put words in my mouth.

I'd like to comment on this since you imply ... but I'll stop here otherwise the ticket indeed becomes a collection of unrelated rants!

Just some very quick comments:

This discussion accelerated before I had the chance to post the general manifest issue at the correct spot. Yes, I realized that and that's why I wrote it.

It is not absolutely random since GraphViz is now on manifest 2 and this issue is connected to it being at manifest 2.

There was no info on the details about manifest 2 you provided on the wiki, so... This however has now changed.

A LTS version provides the opportunity to backport fixes for a period of three years. So if "unstable" things need to be fixed or evolve I'd rather do it at LTS. It's probably a matter of deciding which kind of problems a sysop should encounter. Documentation is always an issue but there is no difference between "regular" and LTS.