Use Semantic Vesioning for DMD Releases
|Author:||(your name and contact data)|
|Implementation:||(links to implementation PR if any)|
|Status:||Will be set by the DIP manager (e.g. "Approved" or "Rejected")|
A proposal to stop using the 2.0XX.X format for DMD releases and begin using Semantic Versioning.
Semantic Versioning (SemVer) has been adopted by numerous software projects around the world. It is a standard with which many developers have become familiar. In contrast, the versioning format used for DMD releases, while not unique, is much less common. It can be confusing to developers who have expectations, thanks to SemVer, about the meaning of each segment of the version number triplet.
In terms of format, SemVer prohibits the use of a leading 0 on any portion of the version triplet, but the middle segment in the DMD version has a leading 0. In terms of behavior, SemVer specifies that the major version should be incremented when a new release of the software introduces changes that are incompatible with previous releases and the minor version incremented otherwise. Currently, the major DMD version is effectively coupled to the language version. Once the 1.0.0 version of DMD was released, the first number was never incremented until development began on a new version of the language (D2). Each "major" release increments the middle number in the triplet, even when the release includes breaking changes. This contradicts SemVer standards and defies the expectations of potential users.
While this is not an issue that has often arisen in the D community forums, it has been brought to the attention of the language authors by software development shops interested in D, but hesitant to use it. It is not cited as the primary reason that these shops are reluctant to adopt D, but as a contribution to the overall impression that the D development community does not follow industry standards. Among the criticisms in this same vein, the complaint about the DMD versioning scheme is the most easily, and painlessly, resolvable.
Someone more knowlegeable than I will have to detail the potential changes in the compiler/runtime/Phobos, if any
Four potential paths are proposed to approach the new versioning scheme. Assuming the first version of DMD to be affected by this is 2.075.0 (for demonstrative purposes):
Simply drop the leading 0 in the middle number, but continue forward with the traditional approach to incrementing the version number. In other words, 2.075.0 would become 2.75.0, the first incremental release 2.75.1, and the next major release 2.76.0. This conforms to the SemVer format, which prohibits leading zeros on each segment of the triplet, while violating the SemVer guidlines for incremementing the version number. This could be an acceptable compromise if it is deemed important to keep the major version of DMD coupled to the language version.
Since the middle number has always been treated as the major version anyway, use it as such in the conversion to the SemVer format. For example, 2.075.0 would instead become 75.0.0. Each major DMD release would then increment the major version if there are breaking changes (76.0.0) and the minor version if not (75.1.0). Incremental releases would increment the patch version. This conforms both to the SemVer format and the guidelines for incrementing the version. It also decouples the DMD version from the language version. Additionally, it has the benefit of clearly showing which of the previous releases preceded it -- 75.0.0 follows 2.074.
Conform to the SemVer format and the guidelines for incrementing the version number as in option 2, but brand the first conformant release as 3.0.0. Rather than showing a clear transition from the last release to use the old format, this option establishes a clean break. An argument can be made that jumping from a major version of 2 to 75 is jarring, while starting with 3.0.0 is more natural.
As option 3, but use version 2.8.0. An argument can be made that if there are breaking changes in this release, then it breaks SemVer by keeping a major version of 2. The counter argument is that the previous release did not follow Semantic Versioning, so it doesn't matter. The next major release can be either 2.9.0 or 3.0.0. This, like option 2, shows a clear succession from the previous release (7x => 8) and allows for a smoother transition than option 3.
yadda yadda yadda
Breaking changes / deprecation process
Tooling? Consider DVM. How will its parsing of the release archive filenames be affected? What about code that tests
__VERSION__? I don't see that any of the proposed options would break that, but am I missing something? Anything else?
Copyright & License
Copyright (c) 2017 by the D Language Foundation
Licensed under Creative Commons Zero 1.0