The version numbers of Endefr consist of six parts: the first four indicate the actual version number and the last two indicate the source of the artifact. Below is a description of each part:
architecture: architectures are incompatible designs of a solution to the problem domain. A new architecture is usually the result of major new requirements or lessons learned from the current implementation.
A new architecture should only be created when important changes cannot be incorporated into the current architecture without breaking backward compatibility and/or introducing unintuitive constructs.
The range of the architecture part is 1+ and the format is an integer without leading zeros.
version: versions add a significant amount of features to the project. The API of a newer versions is backward compatible, but deprecation can be used to migrate to an improved API in the future. In a version, it is allowed to remove parts of the API that were deprecated in its preceding version(s). As a result of this backward compatibility is only guaranteed for the next version.
Please note that using deprecation and actually removing the deprecated API can lead to serious deployment problems. Suppose you want to use two third-party libraries in your application which depend on different versions of the project: 1.01.xx and 1.03.xx. In 1.03.xx parts of the API which were deprecated in 1.02.xx have been removed. Now it is impossible to use both third-party libraries together. If you use the library depending on 1.01.xx, then the other library cannot be used because the features from 1.02.xx and 1.03.xx are missing. If you use the library depending on 1.03.xx, then the other library cannot be used because parts of the API from 1.01.xx that were deprecated in 1.02.xx were removed.
The range of the version part is 1+ and the format is a leading zeros, two-digit integer.
revision: revisions are used for, amongst others, bug fixes, performance improvements, and the addition of a small amount of simple features.
The range of the revision part is 0+ and the format is a leading zeros, two-digit integer.
development status: this part indicates the development status.
The alpha status means that some issues assigned to this revision are still open and the API is subject to change. This status may be skipped for revisions 1 and higher.
The beta status means that the issues assigned to this revision have been resolved and the API is reasonably stable. The final testing and tuning before a release is done while a project has this status.
The gamma status indicates that the artifact is production-ready and that the API will not change in subsequent revisions.
The range for this part is the set of alpha, beta and gamma indicators. The alpha indicator has the range of 1+ and the format is an a followed by a leading zeros, two-digit integer. The beta indicator has the range of 1+ and the format is a b followed by a leading zeros, two-digit integer. There is only one gamma indicator and its format is the empty string.
development: this suffix indicates that the artifact was built from a checked out project, but it is not an official (pre)release. It can contain changes which cannot be found in the CVS. There is also no tag for it in the CVS, so it is difficult to find the committed sources it was based upon.
This suffix will only be used with version numbers with the alpha and beta status. Because of the release management policy only the release manager may use a version number with the gamma status.
This suffix is the string −dev.
distribution: this suffix indicates that the artifact was built from a source distribution (either a development or an official (pre)release). This is not an official (pre)release. It can contain changes which cannot be found in the CVS. For artifacts built from a development source distribution there is also no tag in the CVS, so it is difficult to find the committed sources it was based upon. For artifacts built from an official source distribution there is a tag in the CVS, so the sources it was based upon can be found.
This suffix is the string −dist.
To make the version numbers more concrete, below are some examples:
The version numbers above are all used for official (pre)releases. The first and the third can also be found with the suffixes −dev and/or −dist, and the second only with −dist. The table below summarizes the meaning of the possible suffix combinations:
| - | dev | |
|---|---|---|
| - | Complete suffix: An official distribution built by the release manager from a tag in the CVS. |
Complete suffix: −dev An unoffical distribution built from a check out of the CVS, possibly with uncommitted changes. |
| dist | Complete suffix: −dist An unofficial distribution built from an official source distribution, possibly with uncommitted changes. |
Complete suffix: −dev−dist An unofficial distribution built from an unofficial source distribution, possibly with uncommitted changes |
All version numbers above are used for binary (pre)releases. For source releases −src is appended to the version number, e.g. 1.01.02b01-dev-dist-src.