We do the following steps when we release a new apiVersion ( e.g. 1 to 2 )
1) Update '
' in indy-parent pom.xml. It will update apiVersion in indy-version.properties in
indy-model-core-java during build. This apiVersion will be released along with the client jars.
2) If an api is going to be changed in terms of req/resp message formats or so and we want to support both v1
and v2 users, we need to copy the method to a new one and annotate it with '@Produce "application/indy-v1+json"'.
This method serves old v1 client users. The new method could be placed in a new resource class.
3) We continue working on the v2 version via the original method. This method serves new v2 client users.
4) If no changes to an api, we just leave it as is. All v1 and v2 clients will access it by default.
## Something behind this versioning strategy ##
When client sends a request to Indy, it loads the apiVersion in the 'indy-version.properties' in the
client jar and add a header 'Indy-API-Version' (e.g., 'Indy-API-Version: 1'). When server receives the request,
it goes through ApiVersioningFilter to adjust 'Accept' headers with the most acceptable type being prioritised.
The servlet container respect the priority and choose the right method to use.