This YEP enforces semantic versioning for yaq daemons.
Since yaq is built in a modular way, a typical instrument will rely on many daemons. It is important that client developers have a standard way of recognizing which version of each daemon is installed. Ideally the version information would be semantic: the version string will convey meaning about what has been modified from one version to the next. Semantic versioning is the de-facto standard, and this YEP applies this standard to the yaq ecosystem.
For convinience, yaq daemons are often distributed together in a single package. Often, the package itself will need to have its own version string. Importantly, this YEP does not specify anything about the package versioning strategy. Typically, the daemon versions will not track the package versions, nor will the daemon versions be the same for multiple daemons in the same package. Many yaq packages use date-based versioning.
Each yaq daemon SHALL expose a yaq-rpc method
This method SHALL NOT accept any arguments.
This method SHALL return a string complient with semantic versioning spec 2.0.0.
Refer to the semantic versioning spec for full information.
Briefly, yaq daemon versions shall have the format
Any backwards-incompatable changes (that is, any update which may require yaq-rpc client changes) SHALL increment the
MAJOR part of the version.
Version metadata MAY be appended using a
For example, it's typical to indicate that the git version is being used, e.g. '1.2.3+git`.
yaq daemon versions SHOULD reach 1.0.0 as soon as reasonable. Zero-based versioning results in a less semantically meaningful ecosystem. Typically, a yaq daemon SHOULD reach 1.0.0 as soon as it is put into everyday use on one or more instruments.
Discussion can be found on the gitlab issue for this YEP.
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
built 2020-05-20 22:19:23 CC0: no copyright