search

silverstripe / supported-modules

https://docs.silverstripe.org/en/project_governance/supported_modules/
BSD 3-Clause "New" or "Revised" License
0 stars 2 forks source link

Expand schema to cover unique support levels for each framework version #5

Closed Cheddam closed 4 months ago

Cheddam commented 5 years ago

Currently the module list lacks any detail around:

The schema of the list needs to be updated to support this level of granularity, and we need to fill in this information where possible.

robbieaverill commented 5 years ago

Which version of SilverStripe the module is supported under

We've talked about how to best implement this before, and I think the consensus was that we provide a "supported version constraint" which would define it, e.g. ^1.2 or >=1.2 <4 for example. Some examples of modules that are commercially supported in some versions but not all are fluent, elemental, translatable and multivaluefield.

What level of support for the module is provided for any given SilverStripe version

Do you mean supported dependency versus supported module?

When this level of support will come to an end (based primarily on our roadmap)

I've been thinking about this. I think in terms of the API info we surface it should include a from/to datetime field. In terms of how we manage that data on our end, I think defining it for all modules might become a bit of a maintenance pile - unless they're all the same and we do search/replaces to update them.

One option is that we track CWP entities somewhere else, and they contain the support dates, then we can pull the dates from that in the API controller and attach them to each module.

For the most part I think that module support timelines are directly associated with CWP releases, but there may be some exceptions to this e.g. if we introduce a module in a minor CWP release (like silverstripe-maintenance) or remove one, its start or end date will be different to the rest of the CWP recipe modules. Equally, there are probably some modules (e.g. static publisher) that are commercially supported but not part of CWP at all - these may have arbitrary start and finish dates, or even not have one at all. Another example is silverstripe/framework and silverstripe/cms; these are probably commercially supported from ages ago and to forever.

After I typed all of that - maybe we should just attach this metadata to the module and rely on bulk search/replace to update some whenever a new CWP release comes out (which adds another 18 months of support to everything in it)

GuySartorelli commented 4 months ago

This information won't be maintained in this repo.