Closed stefandesu closed 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).
Looks good, although I don't think splitting and recombining the version number is necessary.
@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. 👍
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). Fieldversion
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).