On 04/29/2014 11:24 AM, Keith Packard wrote:
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.
Either of these sounds fine to me. Having the "major bug fixes only"
date double as the ABI freeze date has a nice simplicity to it. That
window might be a tad short for us to try to target same-day support but
hopefully it's close enough for people.
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.
Sounds good to me. Since I'm reverting the support changes in the
driver, I personally don't care whether the ABI number gets bumped to 18
or not: it's just some minor s/17/18/ in a few places if it does.
--
Aaron
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
