<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Jul 24, 2020, at 9:50 AM, Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<div><blockquote type="cite" class=""><blockquote class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Besides, I think you misunderstood: the point isn't to *forbid*<br class="">flag-day changes. The point is to encourage thinking about how to do<br class="">refactoring better. Sometimes a flag-day change is required, and<br class="">that's fine, but in the vast majority of cases it isn't.<br class=""></blockquote><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">No I perfectly understood, I'm still not in favor of codifying an encouragement in this direction: I'm not eager to have reviewers ask me to change my patch to follow the scheme you describe for stability purposes.</div></blockquote><br class=""></div><div>I can see both sides of this. Deprecation has a lot of value that Nicolai points out and some people do use it. I don’t think it is possible to get to perfect “deprecation cycles” and even outside perfection an overly-broad application of this would just be expensive. Some things (e.g. core IR) simply matter more than others.</div><br class=""><div class="">Perhaps a way too slice this is to phrase it along the lines of:</div><div class=""><br class=""></div><div class="">1) There is no guarantee.</div><div class="">2) That said, for core IR changes it is nice to stage them for XYZ reasons.</div><div class="">3) If you do so, “this is the right way".</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>