llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

> I think the main issue (besides users asking what's the big change in
> 4.0, which I agree is not a big problem) is that the bitcode
> compatibility policy is tied to the major version number.
It is tied in saying we *can* drop compatibility, not that we will. If
we still support loading 3.0 bitcode when 4.1 ships we just have to
document that. It just given us the flexibility to drop it in 4.2 if
we want.

Cheers,
Rafael

On Tue, Jun 28, 2016 at 12:22 PM Rafael Espíndola <cfe-dev at
lists.llvm.org>
wrote:
> > I think the main issue (besides users asking what's the big change
in
> > 4.0, which I agree is not a big problem) is that the bitcode
> > compatibility policy is tied to the major version number.
>
> It is tied in saying we *can* drop compatibility, not that we will. If
> we still support loading 3.0 bitcode when 4.1 ships we just have to
> document that. It just given us the flexibility to drop it in 4.2 if
> we want.
>
>
I don't think this is as obvious as you might think it is. We can happily
drop the "major version equals bitcode compatibility" implicit promise
if
we want, but it's been there for a while and will need some messaging as to
the actual promises here and what we'll do to fulfill and what we mean when
we want to change it (will we actually rev the version? not?). I think
Hans's idea for the release is fine and then will let us argue it as much
as we'd like on llvm-dev until we get a proposal that people are happy with.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160628/324bdf05/attachment.html>

> I don't think this is as obvious as you might think it is. We can
happily
> drop the "major version equals bitcode compatibility" implicit
promise if we
> want, but it's been there for a while and will need some messaging as
to the
> actual promises here and what we'll do to fulfill and what we mean when
we
> want to change it (will we actually rev the version? not?). I think
Hans's
> idea for the release is fine and then will let us argue it as much as
we'd
> like on llvm-dev until we get a proposal that people are happy with.
The promise just says that 4.0 *will* read 3.X and 4.1 might.

I think I agree with Chris with 3.10 being the worst possible outcome.
If the "may be compatible" is too confusing lets change it to be time
base or just say that llvm for now can read bitcode of llvm 3.0 or
newer but we might change that in the future.

Cheers,
Rafael