Display of version compatibility

[animaux]

In lang_german version 2.1.0 it states Symphony 2.4.0 as minimum requirement. Thus it should be shown as compatible with Symphony 2.5.x as well if not stated otherwise by some newer version.

    <release version="2.2.1" date="2015-10-29" min="2.6.0">
        - Transliteration for non-breaking space
    </release>
    <release version="2.2.0" date="2015-07-21" min="2.6.0">
        - Symphony 2.6 compatibility
    </release>
    <release version="2.1.0" date="2014-03-18" min="2.4.0">
        - Symphony 2.4 compatibility
    </release>
    <release version="2.0.0" date="2013-04-03" min="2.3.0">
        - Symphony 2.3 compatibility
    </release>

But instead it says Symphony 2.5.x is not compatible.

[twiro]

In lang_german version 2.1.0 it states Symphony 2.4.0 as minimum requirement. Thus it should be shown as compatible with Symphony 2.5.x as well if not stated otherwise by some newer version.

This is how I understand the description in the official schema documentation too (though it's not that clear on that point), but in fact the current behavior of displaying compatibility might be the better one with regards to long-term reliability of extensions listings:

Right now an extension seems to be marked as incompatible with each new minor release unless explicitly stated otherwise. This rather strict method might automatically mark extensions as incompatible though they're actually working with a newer minor relase, but this looks like the lesser of two evils compared to the other option: having a list full of "compatible" extensions that actually don't work.

This would be the case if we'd follow the contrary method - mark an extension as compatible with each new minor release unless explicitly stated otherwise. This would result in a quite green Compatibility Matrix simply because lots of old and unmaintained extensions don't have reliable max-attributes.

As minor version updates of Symphony don't get released too often I prefer the strict method that's currently used, but maybe we can do better in engaging extension-developers to test and update the compatibility settings of their actively maintained extensions after minor releases (think of extension-hackathons).

If we could agree on a kind of "best practices workflow" regarding how extension developers should treat this topic in the long run this might also make a useful addition to (the upcoming) readme of this repo.

[nitriques]

incompatible with each new minor release unless explicitly stated otherwise.

Following semver, this is not the right thing to do. But since we can't enforce it (and since Sym's API did change from minor version to another, we must keep it like we have).

The simplest thing a developer can do is add the max attribute.

[twiro]

incompatible with each new minor release unless explicitly stated otherwise.

Following semver, this is not the right thing to do. But since we can't enforce it (and since Sym's API did change from minor version to another, we must keep it like we have).

So de facto symphonyextensions.com is doing it wrong (according to semver) because Symphony itself was doing it wrong (according to semver).

But as we switched to semver with Symphony 2.5.0 one should expect that extensions that are compatible with that version will (theoretically) stay compatible with all following 2.X-releases - right?

So wouldn't it be best to use the wildcard syntax 2.X.X as max-attribute for extensions that are compatible with Symphony 2.5.0 (and thus (hopefully) all following 2.X-releases)?

<release version="..." date="..." min="2.5.0" max="2.X.X">
    - Mark version as compatible with Symphony 2.5 and all following 2.X-releases
</release>

This way extension developers wouldn't have to set up a new "yes-its-still-compatible"-release for each minor update of Symphony and actually benefit from the advantages of semver.

@animaux - could you give that a try?
@nitriques - if the "double-wildcard-syntax" 2.X.X works as expected (the documentation isn't clear on that) - wouldn't it make sense to promote this as "Best Practice" for all newer extensions (Symphony 2.5-compatibility and upwards)? If it doesn't work - could you implement it?

[animaux]

Ok, tried that.

[nitriques]

So de facto symphonyextensions.com is doing it wrong (according to semver) because Symphony itself was doing it wrong (according to semver).

Yup.

But as we switched to semver with Symphony 2.5.0 one should expect that extensions that are compatible with that version will (theoretically) stay compatible with all following 2.X-releases - right?

Sadly, no: This will only be possible with 3.0.0

wouldn't it make sense to promote this as "Best Practice" for all newer extensions

No since it would mean that it's compatible with 2.1 as well. (which clearly isn't). But after 3.0.0, yeah, we should.

If it doesn't work - could you implement it?

Yeah for sure!

[nitriques]

One thing that could be done quickly would be to hide deprecated extension in the matrix...

[animaux]

max="2.x.x" seems to do the trick!

[nitriques]

max="2.x.x" seems to do the trick!

Great.

[twiro]

max="2.x.x" seems to do the trick!

That's cool and good to know!

wouldn't it make sense to promote this as "Best Practice" for all newer extensions

No since it would mean that it's compatible with 2.1 as well. (which clearly isn't). But after 3.0.0, yeah, we should.

But extensions with a max-attribute of 2.x.xwould only happen to be displayed as compatible with 2.1as long as they would not have a correct min-attribute, right?

But combining max="2.x.x" with a well-chosen min-value (like in the example I posted above) should work well (according to semver) for everything in the range of Symphony 2.5.0 to 2.x.x - right?

So my proposal was to encourage extension developers to make use of max="2.x.x", but only for extensions that are know to be compatible with at least version 2.5.0. Wouldn't that make sense and help optimizing compatibility information in symphonyextensions.com?

[nitriques]

as long as they would not have a correct min-attribute, right?

This would need some testing, but yeah, that's what should happen!

range of Symphony 2.5.0 to 2.x.x - right?

Should be!

but only for extensions that are know to be compatible with at least version 2.5.0

That's the problem.... It would need a lot of change to actually do this.

[DavidOliver]

So for extensions which have an accurate min value and are known to work with and up to 2.6.7, we should use 2.x.x for the max attribute?

Am I right in thinking that from now on, semver minor releases (e.g., Sym 2.7) should not break any extensions that work with Sym 2.5 (and 2.6)?

[nitriques]

@DavidOliver yes and yes!

[twiro]

That's the problem.... It would need a lot of change to actually do this.

That for sure - but I think writing down some guidelines and best practices will definitively help encouraging developers to take action and make it easier for them to help improving the symphony-extension-ecosystem! This discussion alone seems to have done that to a certain extent ;)

So thanks a lot to everyone participating and spreading the word!

@DavidOliver yes and yes!

Great! So as we agree upon that now I will try to add this info/recommendation to the readme in the next days - that way we will have a kind of "official reference" that can be linked to whenever the discussion comes up for a specific extension... will close this issue after the readme is updated.

[nitriques]

This discussion alone seems to have done that to a certain extent ;)

Yup!

Thanks @twiro