xserver ABI freeze policy

[Aaron Plattner]

On 04/29/2014 11:24 AM, Keith Packard wrote:
> 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.

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