gbv / jskos-server

Web service to access JSKOS data
https://coli-conc.gbv.de/api/
MIT License
6 stars 4 forks source link

Separate JSKOS API version from software version #218

Closed stefandesu closed 7 months ago

stefandesu commented 7 months ago

Having the API version bound to the software version is not optimal because sometimes the software needs updates that are unrelated to the actual API. (For example, we should update JSKOS Server to require Node.js 18, but this should be a major version release.) The API version should be a separate field, e.g. in package.json, and only be updated if there are actual changes to the API.

For the /status endpoint, I would suggest adding a new field serverVersion that contains the version of JSKOS server that's behind the API (to be backwards-compatible). Field version would therefore contain the JSKOS API version.

Edit: I would also pin the current API to version 2.1 and increase the number from there whenever necessary (even though, as far as I can remember, there were no API changes from 2.0 to 2.1).

stefandesu commented 7 months ago

@nichtich

Can you check my commit if everything's okay?

I would create a new release, either 2.1.1 or 2.2.0, with all the changes in dev (mostly dependency updates and small fixes over the last few months).

nichtich commented 7 months ago

Looks good, although I don't think splitting and recombining the version number is necessary.

stefandesu commented 7 months ago

@nichtich Thanks! You're right, we can remove that. It was only in there because we converted the full version number to only major.minor for the API version, but now we can simply specify the versions as they are. 👍