[LLVMdev] Clarification on the backward compatibility promises

[Rafael Espíndola]

On 17 June 2014 16:07, Anton Korobeynikov <anton at korobeynikov.info> wrote:
> Hi Rafael,
>
>> Do others agree that this is the case or at least that this would be a
>> reasonable balance?
> IMO it's easier to be compatible on .ll level, no?

That is not my experience with the bitcode format. The way the API is
structured makes it really easy to support backwards compatibility.

It also seems a lot more valuable from an user perspective to support
reading old .bc files. It means they can keep a library with IR for an
entire major LLVM release for example.

>In case of binary
> IR it's really easy to make incompatible changes. After all there are
> no tests on IR binary compatibility, however the whole regression
> testsuite can be viewed as a big test for .ll compatibility.

We do have tests that are done by checking in old versions of bitcode
files. We didn't use to be good about it, but I think we are now
fairly systematic about it any time we change the format.

> There are two more points here:
>
> 1. Actually we had much stronger policies wrt the bitcode
> compatibility in minor releases. Something like x.y should be able to
> read stuff from x.y-1, but x.y+2 is allowed not to read stuff there,
> so the proper path is transition x.y-1 => x.y => x.y+2. Am I right?

That doesn't match what we have in trunk right now.  For example, we
changed how inline asm is stored in r163185 (Sep 5 2012), but we still
support reading the old one. This is one of the cases where we have a
FIXME about 4.0.

> 2. Metadata compatibility. We already had precedence of introducing
> incompatible changes into metadata format in the past within release.
> Should we use relaxes rules for metadata compatibility?

I think we have a special case for debug metadata (and should document
that), but otherwise I think we should hold metadata to the same
standard as the rest of the IR.

>> In any case, we should probably document whatever we decide. Where
>> should that go? Sean suggested docs/DeveloperPolicy.html. Is everyone
>> OK with that?
> +1

Cheers,
Rafael