common way to list versions of dependencies and components

[soxofaan]

In the VITO and aggregator back-ends we currently list the version of a couple of dependencies/components. For example:

GET https://openeo.vito.be/openeo/1.0/
{
   "_backend_deploy_metadata":{
      "date":"2021-07-13T13:23:16Z",
      "versions":{
         "geopyspark":"geopyspark 0.4.7+openeo",
         "openeo":"openeo 0.8.0.20210625.510",
         "openeo-geopyspark":"openeo-geopyspark 0.5.0a1.20210712.1032",
         "openeo_driver":"openeo-driver 0.10.12a1.20210709.500",
         "openeo_udf":"openeo-udf 1.0.0rc3",
         ...

This turned out handy for end users to follow up if feature request or bug fixes are already available in the dev instance, production instance, ... There is currently the backend_version field in the capabilities doc, but that is often too opaque for tracking particular changes.

Maybe it's useful to standardize a root field in the capabilities doc for this kind of instance/deploy metadata?

[m-mohr]

That sounds like a good idea.

Related fields/definitions (software/facility): https://github.com/stac-extensions/processing

Another idea would be to link to some kind of dependency file, e.g. in JS there is the package-lock.json, which contains all the details regarding dependencies.

[soxofaan]

Another idea would be to link to some kind of dependency file, e.g. in JS there is the package-lock.json

I would keep it simple and not over-specify this or make it too technology specific. At this point I can only imagine this being useful for manual debugging situations, not automated/machine consumption.

[m-mohr]

Actually, the link would be simpler than the proposal above. I mean it would just be a link with a new rel type, but I understand that not all environments have such a file. I really don't have a strong preference here.

[m-mohr]

Hmm, thinking more about it, I think this should be encoded in the backend_version, right? Each new deployment of a back-end (with changes, including dependencies) should issue a new version, I think. Having that, you could track the dependencies and don't require listing them explicitly.

But if you want to list the details explicitly, we can simply re-use STAC fields as the response to GET / is actually a valid STAC catalog. So for versions you'd use processing:software (keys = software, values = version number) and for date you'd use updated (last change of the Catalog, which is basically the deployment date) so that you end up with:

{
  "api_version": "1.1.0",
  "backend_version": "1.1.2",
  "stac_version": "1.0.0",
  "stac_extensions": [
    "https://stac-extensions.github.io/processing/v1.0.0/schema.json"
  ],
  "updated": "2021-07-13T13:23:16Z",
  "processing:software":{
    "geopyspark":"0.4.7+openeo",
    "openeo":"0.8.0.20210625.510",
    "openeo-geopyspark":"0.5.0a1.20210712.1032",
    "openeo-driver":"0.10.12a1.20210709.500",
    "openeo-udf":"1.0.0rc3"
  },
  "type": "Catalog",
  "id": "vito",
  "title": "VITO",
  "description": "...",
  "endpoints": [...],
  "links": [...]
}

This is all valid STAC and already specified. So I'm not even sure we need an API addition here, maybe not even a mention? What do you think?

[soxofaan]

processing:software looks like a good solution to list versions of important dependencies