Version numbers
Please, note that the versioning mechanism presented here applies to both the metadata services (the REST API) and the loading tools. Changes in any would result in a change in the version number reported by the metadata service.
The current version of the API could be fetched using a special metadata service documented in the section Obtaining the current version of the API. The current documentation expects the service to return (upon successful completion of a request as explained in Error reporting in the REST API) the JSON object which has the following value of the attribute version:
{...
"version":17
}
Since workflow implementations would be written with some specific version of the API in mind, they (the workflows) are expected to call this service to see if the implementation is compatible with the current version of the Ingest system of a given Qserv deployment. Formally, both versions should match. Otherwise, it would be hard to predict how the application will behave while attempting to ingest data into Qserv. In some cases, failure caused by version incompatibility may happen at some later stage of the campaign, which may result in wasting time and resources.
As of version 12, the API is offering a more advanced (flexible) mechanism for working with the versions. Please, see details in the JIRA ticket linked from the section Optional version numbers in calls to the REST API.
The default value "