Anyway, aside from that, the main things to know:
x.y.z
if x=0: pre-production development releases, maybe suitable for
regional- or event currencies, but probably not for
regulatory-compliant production systems. No warranties, check the bug
tracker, etc. :-).
y: feature-based milestone, when all components have reached the
milestone, we'll announce the release.
z: minor release per component, used to make minor releases with
bugfixes or new features after a release, and also to make
pre-releases for testing before the release announcement.
None of these are at all indicative of *protocol* compatibility: for
that we have the protocol versioning MAJOR:MINOR:AGE with colons (see
https://tutorials.taler.net/merchant/versioning). In general, we
introduce new features but will remain compatible with *several*
protocol versions back and only drop compatibility when we're pretty
sure that nobody we're aware of is still using ancient code. So no
_need_ to check for versions in general. Exceptions may apply,
especially for x=0 and isolated features, but we try very, very hard
to avoid those already.
So basically, if you want the features of release y, use all
components of y otherwise you might not get the features. Of an
individual component we may at any time make improvements by bumping
z. Don't worry at all about having z differ between components, it is
*normal*.
Once x>0, we'll kind-of use SEMVER where x indicates major new
developments and y indicates fully compatible changes and z minor
patches, but *still* we cannot ever expect everyone to update to a new
version at the same time, so we *must* always be compatible to x +/- 1
version *at least*. For details, the only way to know is to check the
protocol versioning (/config endpoint) for the respective component
via MAJOR:MINOR:AGE as explained in the video-tutorial linked above.
I hope this helps!