Aaron Plattner <[email protected]> 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. -- [email protected]
pgplv_lwaFFmk.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
