[llvm-dev] [RFC] changing variable naming rules

[Hans Wennborg via llvm-dev]

The even bigger issue is that X.1 is supposed to be API and ABI
compatible with X.0.

On Mon, Sep 9, 2019 at 3:35 PM Rui Ueyama <ruiu at google.com> wrote:
>
> Hypothetically assume that we have an LLVM release X and want to rename variables in the next major release Y. In order to backport patches from Y to X.1 smoothly, I think we could first apply the automated renaming tool to X and then cherry-pick patches from Y. The obvious issue of doing this is, even though X.1 is a dot release, a very large number of lines would be changed from X, though.
>
> On Mon, Sep 9, 2019 at 10:21 PM Hans Wennborg <hans at chromium.org> wrote:
>>
>> On Mon, Sep 9, 2019 at 3:03 PM Rui Ueyama <ruiu at google.com> wrote:
>> >
>> > On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at chromium.org> wrote:
>> >>
>> >> On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via llvm-dev
>> >> <llvm-dev at lists.llvm.org> wrote:
>> >> > I'm a little bit curious to hear more about the experiences from the changes in LLD.
>> >> > I’m thinking about things like:
>> >> [..]
>> >> > - merging of bugfixes to older release branches (I doubt that the script supports doing the reverse rewrite as well)
>> >>
>> >> As someone who does a lot of these merges, this is the aspect that
>> >> worries me the most.
>> >
>> >
>> > How large is a typical patch to merge that is backported from the next major release to a previous dot release?
>>
>> The diffs are usually fairly small, but there can be many. For 8.0.1
>> there were about 60 patches merged (git log
>> llvmorg-8.0.0..llvmorg-8.0.1 --oneline | wc -l). (For 9.0.0 I think
>> we're approaching 200 merges.)
>>
>> Depending on when the rename happens, I guess it could affect merges
>> either for a major release or for a dot release, and it would mean a
>> lot of extra work unless there was some tool available to help. Maybe
>> if the rename happens after a dot release ships and before the next
>> major release process begins, it would not affect any merges at all,
>> but that's a pretty slim window, and downstream users might have other
>> release processes.