xserver ABI freeze policy

[Keith Packard]

Aaron Plattner <aplattner at nvidia.com> writes:

> 1. I agree that freezing the ABI multiple months in advance is too long; 
> we don't need *that* much time to get a release tested and out the door. 
>   Let's change the official ABI freeze policy to 4-6 weeks before the 
> final release for each release cycle.  So I guess either the last or 
> second-to-last RC would be the official ABI freeze date?

We've got another hard date in the release process, the 'major bug fixes
only' date, which is June 1 for this release. That's always a month
before the final release, and is the time when we only consider
"major" fixes, generally involving regressions, crashes and other
security issues.

Of course, as the previous two months are also part of the bug-fix
window, any API/ABI changes during that time (which we're in now), would
only be to address bugs in the ABI/API.

Alternatively, we could make a separate ABI/API freeze target during the
bug fix window, perhaps 8 weeks before release. For this release, that
would be this week, but perhaps we should slip that a couple of weeks to
make sure version 18 is solid before declaring it finished.

> 3. I won't care about this particular ABI change for now, and will 
> reevaluate when the official ABI freeze is declared.  I don't care 
> whether that gets called ABI 17 or 18 or whatever.

Awesome.

> Does that sound reasonable?  Someone from AMD should chime in if they 
> care about this too.

Thanks for your help. I propose that we bump the ABI version to 18 for
this release because we have done an RC with the version 17 ABI, and any
drivers built against that will need to be recompiled and/or fixed.

So, ABI version 17 is a 'brown bag' API, and API 18 should be the final
ABI for version 1.16, until we find the next bug which cannot be fixed
in any other way.

Once June 1 rolls around, changing the ABI could only happen in response
to a serious bug in the environment. Let's hope version 18 gets enough
testing that we're able to avoid that though.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140429/c10d288a/attachment.sig>