Symphony.

So where might this information be held?

Either

extension driver about() array

or

a new format, perhaps a standard XML driver/config/definition file that all extensions must contain?

are good in my opinion. The latter feels Symphony-3ish, though.

The latter feels Symphony-3ish, though

Yeah. Which is an interesting point. I see that lots of extensions will be re-written for Symphony 3, and may well retain the same names. So we really need this per-version compatibility, and we also need to establish how this going to work in the land of Symphony 2.

If the structure of extension.driver.php files change significantly between Symphony 2 and 3, then perhaps this is not the place to store the information. Perhaps it needs to reside in an independent file.

I’m all for using a fast forward Symphony 3 style XML format. Something like extension.compatibility.xml.

Another thing that could be nice to have in the extension metadata, is category. Extensions are now categorized in the download area. Same categories could be added to the metadata so those could be categorized also in Symphony backend.

Yes, I see more than compatibility stuff being in the XML. It could replace the about() function entirely. Name, version, release date, author, short description and long description (same as what we have to paste into this site), compatibility, categories…

Same categories could be added to the metadata so those could be categorized also in Symphony backend.

This is already done in Symphony 3:

public function about() {
    return (object)array(
        'name'          => 'Taglist',
        'version'       => '2.0.0',
        'release-date'  => '2010-04-22',
        'author'        => (object)array(
            'name'          => 'Symphony Team',
            'website'       => 'http://getsymphony.com/',
            'email'         => 'team@getsymphony.com'
        ),
        'type'          => array(
            'Field', 'Core'
        ),
    );
}

Nick, also the documentation that can be seen with events, could be in that XML file.

Could the about() method be in Extension class and just search for XML file in the package? I think putting documentation and metadata into the PHP file isn’t good way to go anyway.

Maybe put the “current compatibility” in the about() function? The Symphony site would then fill the compatibility table by going back in time through the commit log, parsing the file on Github.

Yes, the function has to be updated every time there is a new version of Symphony but so does the current compatibility table.

Yes, I see more than compatibility stuff being in the XML. It could replace the about() function entirely.

There aren’t many Symphony 2 versions planned so introducing another forced extension-rewrite could be too much.

There aren’t many Symphony 2 versions planned so introducing another forced extension-rewrite could be too much.

I'm all about forward progress but updates that force an extension-rewrite across the board shouldn't come anytime soon considering 2.2 was just released.

Maybe put the “current compatibility” in the about() function? The Symphony site would then fill the compatibility table by going back in time through the commit log, parsing the file on Github.

I can see the simplicity of this, but I think it adds too much complexity both in terms of server parsing, and that there's no single human readable history in the extension itself.

In terms of comparing versions, will strings such as 2.0.x or 2.0.* work? Imagine if my extension had:

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

Does this look correct? If my extension at 1.3 works with 2.0 to 2.0.5 would I specify a range? Or would it just be:

array(
    '1.3' => '2.0',
    '1.4.1' => '2.0.6',
    '1.5' => '2.2.*',
)

So that the assumption is that 1.3 works with Symphony 2.0 up to, but not including, 2.0.6? With our current implementation, if it hasn't been tested the developer leaves the compatibility as "unknown", so even if the extension works between two Symphony versions (old and new) there is no assumption that it also works in all Symphony versions between.

I'm glad you all agree... ;-)

:P

I'd prefer having the option to specify ranges like you did in your first example. Remember Symphony 2.0.6, 2.0.7 and 2.0.8? We really were in need of compatibility ranges for our extensions at that time.

I agree. I don't think it would be safe to make assumptions on compatibility, so in this example if it were rendered as a compatibility table:

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

If a version isn't included in the array (1.4.0) but the system knows about it, is it "unknown" (?)? Or do we only consider extension versions that are mentioned explicitly in the compatibility array?

Should the extension versions also be arrays so that you could say array('1.4.0', '1.4.6') => '2.0.6'?

If a version isn't included in the array (1.4.0) but the system knows about it, is it "unknown" (?)?

How should the system know of a version that isn't in the array? By calculating missing steps? I think I don't like this kind of auto-guessing.

Should the extension versions also be arrays so that you could say array('1.4.0', '1.4.6') => '2.0.6'?

Is that valid syntax? I didn't know this was possible.

How should the system know of a version that isn't in the array? By calculating missing steps? I think I don't like this kind of auto-guessing.

Exactly. So are we saying that the compatibility array should be the definitive, canonical way of specifying all "listed" versions of an extension? If the developer correctly use tags in their repos, we can use the Github API to see if tags exist, and auto-link to the correct version URLs directly in the repo (and allow zip downloads of each too).

Is that valid syntax? I didn't know this was possible.

No, probably not as it is, but it's more the concept I'm getting at rather than the syntax. Might we want to allow the developer to specify a range of extension versions against a range of Symphony versions, or should the list of extension versions be singular only? If I release three very quickly, say 1.1, 1.2.0 and 1.2.1, and these are all compatible with the same Symphony versions (say, 2.1 to `2.2), would I add all three of these to the compatibility list separately:

1.1 => (2.1.*, 2.2.*)
1.2.0 => (2.1.*, 2.2.*)
1.2.1 => (2.1.*, 2.2.*)

Or as an array:

(1.1, 1.2.0, 1.2.1) => (2.1.*, 2.2.*)

Or maybe I just wouldn't bother adding 1.1 and 1.2.0, instead just adding 1.2.1, if I'm quite sure that I'm releasing versions so quickly that people aren't updating as I release.

From what I can see, the first idea is less complex and is only a question of copy and paste. I'd prefer that.

[...] in this example if it were rendered as a compatibility table:

Nice!

Should the extension versions also be arrays so that you could say array('1.4.0', '1.4.6') => '2.0.6'?

It would add too much complexity in my opinion. Let's keep it simple!

Should the extension versions also be arrays so that you could say array('1.4.0', '1.4.6') => '2.0.6'?

It would add too much complexity in my opinion. Let's keep it simple!

I agree.

You're in the "okay, this is version so and so and works with this and that" mindset already. So for most people it'll probably be easier to simply add a new line when releasing a new version.

Cool.

When I "range", I'm not sure I mean range.

1.2.0 => (2.1.0, 2.2.0)

I thought this might be a range, from 2.1.0 to 2.2.0 but maybe this assumption is bad, and the array should contain the actual list of versions it's been tested against. If the version isn't explicitly in the array (e.g. 2.1.1) we mark it as "unsure"?

So it'd actually be:

'1.2.0' => ('2.1.0', '2.1.2', '2.1.2', '2.2.0')

If the version isn't explicitly in the array (e.g. 2.1.1) we mark it as "unsure"?

Yes, ranges are tricky to handle (what if you want 2.1.0 - 2.2.0 but not 2.1.2?). Make it a simple list of "OKs" and everything else is "unsure".