<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 24, 2015, at 4:19 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">FWIW, we need to specify this stuff much better. The current situation is actively harmful.<div class=""><br class=""></div><div class=""><br class=""></div><div class="">Also, Filip, if you want the open source releases to be known to work with webkit, you *need* to start testing sooner. It is pure chance that this could get into any release. If it doesn't make it, and goes in the .1 release, so be it.</div></div></div></blockquote><div><br class=""></div><div>WebKit currently does not test against LLVM tip-of-trunk; we usually bless some revision and live on it for a while.  Also, different WebKit ports have different policies.  We're not in a hurry to change this approach, because we have enough other stuff going on.</div><div><br class=""></div><div>LLVM should have its own process in place for ensuring that C API stability guidelines are obeyed.  These guidelines, as I understand them, are that once a C API function or type makes it into a release, it must not be removed without some period of deprecation.  Function names, signatures, type names, and enum members should be part of that to enable source-level compatibility.  If that isn't the policy now, then that's the policy I would ask for.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">However, I don think it is reasoonable to fix. I think the fix needs to be somewhat different. It needs to say that this has no effect and is deprecated and will go away in the next release, and the release notes need to say that as well.</div></div></div></blockquote><div><br class=""></div><div>Here is an improved fix for trunk.  I tend to think that reverting is safest for the branch.</div><div><br class=""></div><div></div></div></body></html>