<div dir="ltr">It would probably better for whoever wrote this text to pipe in, but I think the idea is that (X+1).0 is supposed to be a kind of a "bridge" release.<div><br></div><div>That is, if you have legacy IR files that contain dropped features, or if the IR format changed significantly, you can still use the (X+1).0 auto-upgrade (which may be fairly complex) to read them, but this auto-upgrade complexity may be dropped in (X+1).1.</div><div>I'm not completely sure this makes sense, but this is how I've always understood it.</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 13, 2016 at 10:22 AM, Renato Golin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13 June 2016 at 18:02, Rafael Espíndola <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>> wrote:<br>
> It is documented at<br>
><br>
> <a href="http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility" rel="noreferrer" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility</a><br>
<br>
</span>This is weird...<br>
<br>
"The bitcode format produced by a X.Y release will be readable by all<br>
following X.Z releases and the (X+1).0 release."<br>
<br>
Why (x+1).0 ?<br>
<br>
--renato<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div></div>