1.11 release process (was: [PULL] -next branch for 1.11)

[Daniel Stone]

Hi,

On Tue, Mar 01, 2011 at 08:44:20AM -0800, Jeremy Huddleston wrote:
> On Feb 28, 2011, at 22:53, Keith Packard wrote:
> >> 2) I think the early rcs might not have been as well tested because
> >> they relied on xextproto and randrproto versions that were not
> >> released.  Perhaps we should ensure that we release rc protos along
> >> with rc servers where appropriate.
> > 
> > Do you want to keep X server code from being merged until a suitable
> > proto RC has been released? Or is it sufficient to have code in the
> > proto repo that has been reviewed?
> 
> I think that locked-step changes should be done as simultaneously as possible.  We should try not to merge proto updates that cause the server to stop building (as was the case with randr for a while) until both sets are reviewed and can be pushed together.  The same goes for tagged releases.  I think we should've pushed rc tags of extproto and randrproto to coincide with the server rcs. This would allow someone to build the rc server entirely from tarballs which might allow for more exposure.

Yeah.  So, taking the RandR case as an example:
    * RandR 1.3.99.0 gets merged to master with an unstable API,
      _provided it does not break 1.3 and prior users_;
    * RandR 1.3.99.1 could change the API that 1.3.99.0 introduced;
    * (and so on, and so forth);
    * RandR 1.3.99.900 gets merged, and at this point would be
      API-stable - additions only.

At that point, the only thing that could go wrong would be merging
anything depending on 1.3.99.0 or 1.3.99.1 or whatever into the server,
but just don't do that.  Merging code depending on 1.3.99.900 and beyond
would be fine.

This preserves bisection completely, except when something depends on
x.y.99.z, where z < 900.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110302/501768b5/attachment.pgp>