<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 28, 2016 at 12:45 PM Rafael Espíndola <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I don't think this is as obvious as you might think it is. We can happily<br>
> drop the "major version equals bitcode compatibility" implicit promise if we<br>
> want, but it's been there for a while and will need some messaging as to the<br>
> actual promises here and what we'll do to fulfill and what we mean when we<br>
> want to change it (will we actually rev the version? not?). I think Hans's<br>
> idea for the release is fine and then will let us argue it as much as we'd<br>
> like on llvm-dev until we get a proposal that people are happy with.<br>
<br>
The promise just says that 4.0 *will* read 3.X and 4.1 might.<br></blockquote><div><br></div><div>Yes, but while you have read it and interpreted it precisely, I suspect that many people have misinterpreted it and assume that 4.0 will be the last release to read 3.X. They may be incorrect, but I think it would still be worth considering them and working to communicate this effectively.</div><div><br></div><div>Essentially, what Eric said: it may be accurate, but it isn't *obvious*, at least not to everyone.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think I agree with Chris with 3.10 being the worst possible outcome.<br></blockquote><div><br></div><div>I'd be interested to understand why you or Chris thing 3.10 is the worst possible outcome.</div><div><br></div><div>Chris has said it is because he thinks we'll never change the "3", but I don't understand why 3.10 is worse than 3.9 was in that respect. I happen to agree that we'll never change the "3", but I don't think this makes 3.10 a particularly bad choice.</div><div><br></div><div><br></div><div>I'm seeing pretty much zero support for continuing to have a major/minor split. As such, I pretty strongly suggest that as a community we move to a single integer that increments every (time based) release, and a .N that increments with every patch release off of that branch. GCC and numerous other projects work this way.</div><div><br></div><div>I actually don't care at all what the number is: 4 or 40 seem fine.</div><div><br></div><div>If 4 seems too confusing, and 40 seems too extreme, how about 10. Seriously. It seems exactly as good as any other integer to start counting rationally, and won't confuse people by looking like a 4.0 release.</div><div><br></div><div>My 2 cents.</div><div>-Chandler</div></div></div>