[LLVMdev] Clarification on the backward compatibility promises

[Rafael Espíndola]

A bit of history first:

Back when we transitioned from bytecode to bitcode (2.0) we had a tool
called llvm-upgrade which would read .ll files from 1.9 and output 2.0
format which could then be passed to llvm-as to produce bitcode.

The release notes for 2.3 note that llvm-upgrade was not supported any more.

During the 2.X development we tried to keep reading older bitcodes.
Once we got to 3.1, we dropped support for reading 2.X:

http://llvm.org/viewvc/llvm-project?view=revision&revision=145165

Since then we make sure that when IR format is changed we upgrade as
we read the bitcode and mark those code paths with something like "//
TODO: Remove with llvm 4.0".

There is some support for parsing .ll files, but we have not been
nearly as systematic about it.

So, what IR do we promise to be compatible with?

>From the above history, it looks like the working assumptions are

* The is no strong guarantee about .ll compatibility. We don't make
gratuitous changes and when desirable/requested we do keep support for
old syntax around for some time and in some cases issue warnings about
it. In summary: it is fuzzy, don't assume much about it.

* All of llvm's 3.X and 4.0 releases will be able to read and upgrade
bitcode produced by all preceding 3.X releases (except for bugs).

* Once 4.0 is released, trunk may drop support for reading bitcode
produced by 3.X. We may then decide to keep some support, but we don't
offer any promises.

Do others agree that this is the case or at least that this would be a
reasonable balance?

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

Cheers,
Rafael