Adam Jackson, who was responsible for preparing several past releases of X.Org Server, in his report at the conference proposed switching to a new release numbering scheme. To make it clearer how long ago a particular release was published, similar to Mesa, it is suggested that the first number reflect the year. The second number will indicate the ordinal number of a significant release for the given year, while the third number will reflect corrective updates.
Moreover, since X.Org Server releases are now quite rare (X.Org Server 1.20 was released a year and a half ago) and there is currently activity towards forming X.Org Server 1.21, while some fixes and innovations have accumulated in the code, it is proposed to move to a planned model for creating new releases.
The proposal is that the code base will continuously evolve using a continuous integration system, and a release will represent a simple snapshot of the state on predetermined dates, provided that all CI tests pass successfully.
Significant releases, including new features, are planned to be formed every 6 months. As new features are added, it is also suggested to create intermediate builds that can branch automatically, for example, every two weeks.
Hans De Goede (Hans de Goede), a developer of Fedora Linux working at Red Hat, , the proposed method is not without its drawbacks — since X.Org Server is heavily tied to hardware, not all issues can be caught through the continuous integration system. Therefore, it is additionally proposed to introduce a system for blocking release errors, where the presence of such errors would postpone the automated release, as well as to organize the formation of pre-releases for testing before the final release. Michael Dänzer, a Mesa developer from Red Hat, , noted that the proposed method is good for snapshots and release candidates, but not for final stable releases, partly due to the possibility of ABI compatibility breaking in intermediate releases.
Source: opennet.ru
