Changes between Version 1 and Version 2 of OtherReleaseExamples


Ignore:
Timestamp:
Jun 16, 2009, 9:45:07 PM (8 years ago)
Author:
jreed
Comment:

Some X.org example notes. (By the way, I have done three official releases of individual X.org components so I do have some real experience with X.org releng.)

Legend:

Unmodified
Added
Removed
Modified
  • OtherReleaseExamples

    v1 v2  
    4343 * one release candidate released each week (for last fifteen days)
    4444
     45=== X.org-style Release Process ===
     46
     47X.org doesn't have the policies and schedule defined nor documented.
     48X.org as a whole X11 is based on over a hundred different components
     49(called packages or modules) which have their own developers and
     50releases.  There is no defined schedule or cycle. And
     51no regression testing plan or quality control
     52and no policy for communication with other developers.
     53No individuals are responsible. No policies on locking the tree
     54and no locking APIs/ABIs.
     55Only fairly loose guidelines.
     56
     57 * For individual components:
     58   * For most components, any individual with SSH privilege may decide to roll out a new release of some component without any discussion.
     59   * Individual developer may or may not work with others to decide when to release.
     60   * No official policy to do beta releases or even to announce intent to release.
     61   * Components may sync up with whatever components are convenient (so could be old releases or development code from git master).
     62   * APIs may change that break other existing official components.
     63   * Increase number (like in configure.ac) for release version.
     64   * Private and informal testing.
     65   * Tag in git.
     66   * Create tarballs and upload tarballs.
     67   * Create checksums.
     68   * Announce release with PGP signed email to xorg-announce.
     69
     70 * For xorg-server:
     71   * Usually a two or three month cycle.
     72   * Sometimes announcements of intent to "bundle" up a new xorg-server is done
     73   * Various fixes from git master are hand-selected to pull into it.
     74   * Sometimes announcements of beta testings of the release are announced.
     75   * Informal testing.
     76   * Attempt is made to avoid breaking ABIs.
     77
     78 * For X.org X11 as a whole.
     79   * This release basically identifies the versions of the components that work together -- even if they aren't the latest versions blessed by the interested component developers.
     80
     81The end result is that third parties and vendors have to do their own quality control, patching, and preparation to provide their own X.org. Commonly, new component releases will be incompatible with other official components due to developers working only with old, custom, or git master (bleeding edge) dependencies -- or lack of full X.org testing. As a common example, new xorg-server releases often break several video drivers.