The evolution strategy of the API is gracefull degradation over versioning.
This means you will not see /v2/ in the URLs. Instead you (the client) will have to update your code according to the non-breaking changes implemented in the API as it evolves.
Hence it is important to be conscious of the definitions of breaking and non-breaking changes:
A breaking change is a change in API semantics or format.
Let's say a color element initially contains data on the exterior color of a car, but changes so that is describes the interior color of the car.
A non-breaking change is removing and adding data.
Let's say again the color element contains data on the exterior color of a car. Later, an interior-color element is added, holding data on interior color off course. Also, a field may simply disappear. It is important to recognize that this is not a bug but simply a result of business rules evolving. As you might have noticed, there is an important distinction between semantics/formats and data
When parsing the feed or entry, all elements defined in the finn:adata element are subject to change. You should parse it in a fail-safe manner. Fields may be removed or added (non-breaking change). This is why the name of finn:field defines name as an attribute, instead of being reliant on an XML schema. So if a price is being changed from a number to a string, this will be added as a new field, and the old one will eventually be removed. This is to prevent versioning of the API, making both server and clients support multiple versions. Check out the model -attribute of the finn:field to see what to expect from the ad data.
Here's an example of an ad model describing the data from a car-used-sale ad:
{
"name":"seats",
"description":"Number of seats",
"mandatory":false,
"multi-value":false,
"searchable":false,
"type":"number"
}