Symphony.

I think it'd be too complex. It's taken quite a long time (18 months?) to get all extensions onto Github, so introducing a new concept is adding to the maintenance overhead in my opinion. Because this is a fundamental change to the way developers maintain extension meta data I'm keen to retain as much familiarity as possible.

Will we be hard pressed to make progress on the above for Symphony 2.3?

I've opened #767 so we don't forget this for 2.3. As mentioned in the issue, at minimum 2.3 should offer a way for extensions to specify compatibility, dependencies and extension type.

Will we be hard pressed to make progress on the above for Symphony 2.3?

Sorta, it'd be handy if someone wants to take ownership of it and run with it until completion.

Sorta, it'd be handy if someone wants to take ownership of it and run with it until completion

@designermonkey and I have been keen to work on extension management, so this is an obvious step. John, shall we work on nailing this badboy?

Yes. We shall discuss it.

A quick note to all that this has pretty much been finalised in #767 and we're hoping to get the most basic implementation ready for Symphony 2.3. As an extension developer you don't need to do anything yet.

(Edit: unpinned discussion from top of forum)

I've been giving this a lot of thought. Like, more than any human should reasonably afford. And I think all of the compatibility things we've discussed above are good, but still clunky. They aren't immediately obvious, readable, and require significant developer effort.

Simone made the excellent point that the most succinct view for the user is to just show when compatibility is broken. Why show anything else?

To this end I'm suggesting a much simplified syntax for documenting versions, release notes and compatibility.

<releases>
    <release version="0.3" date="2011-03-03" min="2.3" max="2.4"/>
    <release version="0.2" date="2011-02-02" min="2.2.2">
            ...
    </release>
    <release version="0.1" date="2011-01-01" min="2.0"/>
</releases> 

https://gist.github.com/1114078

A release element has:

• version: number (should match a git tag if possible), required
• date: ISO date of release, required
• min: the lowest Symphony version required, optional but recommended
• max: the last version of Symphony that it works with (if broken with a newer Symphony release)

This way, the max attribute is kind of temporary, until the author releases a new version of the extension that fixes compatibility.

The syntax is immediately readable, doesn't try and include ranges (using min and max together creates a range), and doesn't require any crazy parsing. And I think it's easier to developers to maintain.

This makes sense, and well thought out old bean.