<div dir="auto">Hi Hans,<div dir="auto"><br></div><div dir="auto">I suggested merging only the new API to 7.0.0. Not doing the port and not deprecating the old API. Did you miss that?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">Stephen. </div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 13 Aug 2018, 09:48 Hans Wennborg, <<a href="mailto:hans@chromium.org">hans@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hmm, if we merge the deprecation notices to 7.0.0, we'd also need to<br>
merge all the clang, clang-tools-extra, etc. updates to avoid the<br>
warnings in our own code, at which point we would have merged the<br>
whole thing, and I'd prefer not to do that.<br>
<br>
I think just having a clear release note for 8.0.0 explaining what's<br>
changed and what developers need to do is good enough. I believe<br>
that's how API changes normally go.<br>
<br>
On Fri, Aug 10, 2018 at 7:35 PM,  <<a href="mailto:paul.robinson@sony.com" target="_blank" rel="noreferrer">paul.robinson@sony.com</a>> wrote:<br>
> If the totality of the change is deemed too large to backported, it could<br>
> make sense to only backport the new API and made a message to the release<br>
> notes to encourage downstreams to port.<br>
><br>
><br>
><br>
> This is a lot kinder to downstream consumers than usual, and I fully support<br>
> doing it that way.<br>
><br>
> --paulr<br>
><br>
><br>
><br>
> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev-bounces@lists.llvm.org</a>] On Behalf Of Stephen<br>
> Kelly via cfe-dev<br>
> Sent: Friday, August 10, 2018 1:19 PM<br>
> To: David Chisnall; Hans Wennborg<br>
> Cc: Clang Dev<br>
> Subject: Re: [cfe-dev] API Removal Notice (4 weeks): getStartLoc,<br>
> getLocStart, getLocEnd<br>
><br>
><br>
><br>
> Hi David,<br>
><br>
><br>
><br>
> I think that's a release manager decision (cc Hans)<br>
><br>
><br>
><br>
> The API doesn't exist in 7.0.0. All of my commits (introduce the new API,<br>
> port to it, deprecate the old API) would have to be backported.<br>
><br>
><br>
><br>
> In discussions so far, it was not a priority to keep the old API or notify<br>
> particularly sensitively.<br>
><br>
><br>
><br>
> If the totality of the change is deemed too large to backported, it could<br>
> make sense to only backport the new API and made a message to the release<br>
> notes to encourage downstreams to port.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
><br>
> Stephen.<br>
><br>
> On Fri, 10 Aug 2018, 14:44 David Chisnall, <<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" rel="noreferrer">David.Chisnall@cl.cam.ac.uk</a>><br>
> wrote:<br>
><br>
> On 10 Aug 2018, at 00:13, Stephen Kelly via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>><br>
> wrote:<br>
>><br>
>> All third-party code must be similarly updated.<br>
>><br>
>> Currently, the old names remain in the code, but annotated as deprecated.<br>
><br>
> If you haven’t already, please will you add this change to the set to be<br>
> backported to the 7.0 branch?  The deprecation notice was really useful - it<br>
> told me exactly what I needed to change to make it go away - but if it never<br>
> ships in a major release then a lot of downstream users will never see it.<br>
><br>
> David<br>
</blockquote></div>