Adam Jackson, who was responsible for several past releases of X.Org Server, in his report at the conference switch to the new issue numbering scheme. In order to more clearly see how long ago this or that issue was published, by analogy with Mesa, it was proposed to reflect the year in the first number of the version. The second number will indicate the significant release number for the year in question, and the third number will reflect corrective updates.
In addition, since X.Org Server releases are now quite rare (X.Org Server 1.20 was released a year and a half ago) and so far activity on the formation of X.Org Server 1.21, while some corrections and innovations have accumulated in the code, it is proposed to move to a planned model for the formation of new releases.
The proposal is that the codebase will be continuously developed using a continuous integration system, and the release will be a simple snapshot of the state at certain pre-scheduled dates, provided that all CI tests are successfully passed.
Significant releases, including new features, are planned to be generated every 6 months. As new features are added, it is also proposed to generate intermediate builds that can automatically branch, for example, every two weeks.
Hans de Goede, Fedora Linux Developer at Red Hat, that the proposed method is not without flaws - since the X.Org Server is very much tied to the hardware, it will not be possible to catch all problems through the continuous integration system. Therefore, it is proposed to additionally introduce a system of blocking release errors, in the presence of which the automatic release will be postponed, as well as organize the formation of preliminary releases for testing before the release. Michel DΓ€nzer, Mesa Developer at Red Hat, that the proposed method is good for snapshots and release candidates, but not for final stable releases, also due to the possibility of getting an ABI compatibility break in an interim release.
Source: opennet.ru