Add new API endpoint to determine whether a list of modules and versions are supported

[robbieaverill]

As part of the site summariser work (https://github.com/bringyourownideas/silverstripe-maintenance/issues/34) we'd like to be able to identify whether a list of SilverStripe modules are commercially supported.

We talked about using a composer.json keyword like "supported", but this falls down when certain versions of a module are supported and others are not, and also would allow community devs to mark their own modules as supported which could skew the data.

Another option could be to create an API endpoint on this website which can take in a list of modules and versions and return whether or not they are supported.

Addons could have a "support constraint" field added to the Addon model which could indicate which versions of the module are supported (or use * for all), and when it detects new released versions of modules it could check the constraint for support and if matched then add 18 months (?) to a "support end date" field for that addon's version.

This way we could do a request like this:

$ curl https://addons.silverstripe.org/api/support?modules={"silverstripe\/framework":"3.4.1","silverstripe\/userforms":"4.5.5","foobar\/baz":"1.2.3"}

{
    "silverstripe/framework": true,
    "silverstripe/userforms": true,
    "foobar/baz": true
}

This would allow us to handle complex support commitments for modules like silverstripe-elemental and silverstripe-fluent, which are commercially supported by SilverStripe for the SilverStripe 4 compatible versions, but not for SilverStripe 3. Including the "support end date" field would also ensure that we are not providing false indications of support on older modules like silverstripe-translatable which are still supported in SilverStripe 3 but not for SilverStripe 4 or newer.

cc @clarkepaul @chillu @unclecheese

[chillu]

it could check the constraint for support and if matched then add 18 months (?) to a "support end date" field for that addon's version

This would be codifying a process and commitment that doesn't exist - in the best case, it'll be shorter than our actual commitment, in the worst case it'll contradict what we say on silverstripe.org/roadmap. I think it's a good idea to build in "end date" support for this API, but not to pre-set it. I think for now, "you're on a supported module, there's a newer version available" is enough comms. What exactly "supported" means can be quite context dependant.

I would just have a single API endpoint that outputs a (cached) list of all modules we support. That could have other uses like providing module lists for build status tools, our combined Github search, etc.

[robbieaverill]

I would just have a single API endpoint that outputs a (cached) list of all modules we support

Are you concerned about indicating that Fluent, Elemental and Translatable (for example) are supported in SS3 or SS4 when we're only supporting them in one of those two?

[chillu]

Are you concerned about indicating that Fluent, Elemental and Translatable (for example) are supported in SS3 or SS4 when we're only supporting them in one of those two?

I was thinking of a single API endpoint (one list rather than search abilities) in order to simplify the implementation. I think SS3 vs. SS4 support in modules is implicit by which release lines of that module we support. For translatable, we just wouldn't declare "supported module" status for the module's 3.x release line (which is compatible with SS4). So in the end, "supported module" means "one or more supported release lines in a module".

[robbieaverill]

Follow up hotfix commit here: https://github.com/silverstripe/addons.silverstripe.org/commit/c0f56f8d35a70f78883277f8d71a98733f81ab0f