Symphony.

I think Nick's suggestion is almost on the money. I'd just remove ranges. Anything that's no specified in the compatibility array would be marked as unsure.

array(
    '1.3' => array('2.0', '2.0.5'),
    '1.4.1' => array('2.0.6', '2.1.0'),
    '1.5' => '2.2.1',
)

The question then is, how do we reference when this are not compatible? If everything omitted is marked as unsure, then the above example how would we determine 1.3 on version 2.0.6 be marked as 'No' not 'Unsure'?

Maybe it depends on how we show this in the UI. In my table above I have a full matrix of extension versions against Symphony versions. Perhaps we just need a list of Symphony versions, and the recommended extension version. I assume users approach this from a Symphony version perspective: "I'm running Symphony 2.1, which version of Order Entries should I use?".

This means we don't need to make an assumption that 1.3 does or doesn't work on versions other than those stated. As a user I know I'm running Symphony 2.0.6, and I can see that I should run extension version 1.4.1. It could well be that 1.5 is also compatible with Symphony 2.0.6, in which case that would also go into the array for 1.5, and would the suggested version in the table (always suggesting the highest extension version that is explicitly compatible).

As a user, what's important to me isn't that both 1.4.1 and 1.5 are compatible with Symphony 2.0.6 (I don't really care), but that I should be using 1.5 — the best available version for my Symphony build.

(Actually, this is pretty much what Simone suggested above, but instead of leading by extension version number, I'm suggesting leading by Symphony version.)

This still doesn't answer how to explicitly mark incompatibility. Let's say I stop maintaining my extension at version 1.5 and I know for sure that it won't work with Symphony 2.3 or higher, but I have no intention of updating it to work. It should say No against Symphony 2.3. We could just mark all missing versions as ? as in the table above. But when Symphony 3 arrives, we'll have a sea of question marks, when we know full-well that 100% of extensions will be incompatible on day one.

Does there need to be an additional syntax?

'1.5' => array('2.2.*', 'not 2.3.*')

What about extensions that might be compatible with 2.3, because they're not affected by

Maybe, looking at your example above, we should mark versions that are missing in the range as "unsure" (like 2.1.1 and 2.2) and versions that are outside the lowest or the highest compatible Symphony version as "incompatible" (e. g. 1.7 and 2.3 in your example). If Symphony 2.3 will be release we should not assume that extension continue to work until the developer sets it actively.

(Hopefully you see what I mean ...)

Maybe it's an idea to mark missing maintenance releases (x.x.1) as unsure while marking missing major (2.x.x) or minor (x.1.x) release as "incompatible".

Reminder to look more closely at how Omeka do this, looks similar.

The extension ecosystem is really strong now. I think we should try and finalise a format for this versioning stuff and implement it where we can. Symphony 2.3 might introduce breaking changes, so it makes sense to have the versioning syntax resolved before then, so when developers update for 2.3 they can add it at the same time.

Having just re-read the thread to refresh my memory, I think the consensus is that an array in the extension.driver.php is the best way to store this information. It should be in the form:

array(
    '1.3' => array('2.0', '2.0.5'),
    '1.4.1' => array('2.0.6', '2.0.8'),
    '1.5' => '2.1.*',
    '1.6' => '2.2.0',
)

A developer explicitly states which versions of Symphony are compatible with each version of their extension. Not all versions of the extension need to be listed, so if I release 1.4.0, 1.4.1, 1.4.2 and 1.4.3 in quick succession, I only need to list 1.4.3 since I assume that users won't be wanting these specific, possibly buggy maintenance versions.

The arrays above are not ranges but explicit Symphony versions. Entire groups of releases can be marked with wildcards. So in the example above, version 1.5 is compatible with any Symphony version of 2.2.*, including any future releases in 2.2.

Only Symphony versions stated explicitly get a YES for compatibility. Symphony versions not stated receive a NO.

We didn't discuss Nils' last comment:

Maybe it's an idea to mark missing maintenance releases (x.x.1) as unsure while marking missing major (2.x.x) or minor (x.1.x) release as "incompatible".

With my example array above we have missing compatibility information for the following Symphony versions. So can we supplement a MAYBE for some versions where my Symphony version is between two that the extension is compatible with?

• 2.0.1, 2.0.2, 2.0.3, 2.0.4 — could assume MAYBE with 1.3?
• 2.0.7 — could assume MAYBE with 1.4.1?
• 2.2.1, 2.2.2 — could assume MAYBE with 1.6?
• 2.3 — could assume MAYBE with 1.6, or NO entirely since it's a new minor release of Symphony?

Very nice!

• 2.3 — could assume MAYBE with 1.6, or NO entirely?

It should be a NO in my eyes because it's a future version from the extension's perspective. Even if Symphony 2.3.3 had already been released, the newest version known to the extension would be 2.2.

I agree Nils about future version numbers.

Also, if the specific version number isn't in the array, it should always be a MAYBE (or UNTESTED), as the developer hasn't included it.

Yeah I like something more explicit like UNTESTED

I agree Nils about future version numbers.

Me too.

Presently I'm doing horrible regex string parsing on the about() method. I don't want to have to instantiate the entire extension class just to read it. Is there an easier way?

Ok so this came up again quickly on Github, so we really need to nail this down.

As Nick's discovered, parsing the information from the about() array is horrible. One current annoyance when dealing with extensions is that you have to create an instance of one first before you can get it's about() functionality. It's a pain in the ass. While, about() should be static, it still doesn't solve the issue completely.

We have mentioned it before, but I think a separate meta.xml file would be a better option. It's XML, so it's something we're already comfortable with (including developers), it's easily parsed and doesn't require regex. There is the concern then of duplication with about(), but what if about() no longer exists?

What if the about() function was deprecated in favour of a meta XML file? Symphony 2.3 would support both, but future versions could just use the XML file. I think it'd be a cleaner approach.

I like the sound of that.

We did consider this at the start of this thread:

Agreed! A source of mistakes, and a pain in the bum. Problem is, the README file can be anything (plain text, Markdown, YAML etc.) and the extension.driver.php is PHP. The saviour in my eyes would be a new file, extension.meta.xml or something, which contains the extension’s about array as XML instead. This could be made fairly human readable, and would be machine-readable by Symphony and this website. But it’s a departure from established conventions.

We've got 285 extensions, all with about() methods. I don't think anyone is going to have time to get all of these updated with an XML file, regardless of the benefit. One option is to say "your extension won't appear on the new Symphony site until you add the extension.about.xml to the Github repository". This would potentially weed out old and un-maintained extensions. But let's be under no illusion, a small decision idea like adding an XML file now could be a massive undertaking for the whole community.

I'm not against the idea itself, just the burden of work it puts on extension developers, given there is already a well-established convention for storing meta data. I'm tempted to say let's stick with that we have (it works, well), and work on a way of parsing it out for our own purposes.

Depending on the schema of the XML file, I don't mind going through mine and the Symphonists extensions and doing it...

This would potentially weed out old and un-maintained extensions.

Definitely a benefit to be considered.

I think I could handle creating a few XML files, myself. But I have only a small number of extensions to deal with.

I say let's do it. It'll make a lot of things easier in the long run. Some enterprising soul among us could probably write a script that bootstraps the conversion process a bit.

Do we already have an example somewhere how the XML could look like?