On Jul 24, 2020, at 9:50 AM, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Besides, I think you misunderstood: the point isn't to *forbid* > flag-day changes. The point is to encourage thinking about how to do > refactoring better. Sometimes a flag-day change is required, and > that's fine, but in the vast majority of cases it isn't. > > 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. 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. Perhaps a way too slice this is to phrase it along the lines of: 1) There is no guarantee. 2) That said, for core IR changes it is nice to stage them for XYZ reasons. 3) If you do so, âthis is the right way". -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200726/b9256d8a/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4