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

On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
>
> > On Jun 13, 2016, at 4:54 PM, Hans Wennborg <hans at
chromium.org> wrote:
> >
> > Breaking this out into a separate thread since it's kind of a
separate
> > issue, and to make sure people see it.
>
> Thanks!
>
> >
> > If you have opinions on this, please chime in. I'd like to collect
as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
>
> (basically repeating my point of the other thread here)
> Bumping the major version number without changing the bitcode
> compatibility rule would mean dropping the current guarantee on this
> aspect. I doubt we want to go this route without a good reason.
>
Completely agree with you here: unless we have a reason to break backwards
compatibility at the bit code level for this release, I don't see a
compelling reason to bump the major version number to 4.0.  As such, I
would expect that the next release would be 3.10.

> --
> Mehdi
>
>
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> change?
> >
> > - We've never had an x.10 version before; maybe that would be
> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39
->
> > 3.0 and 3.19 -> 4.0).
> >
> > - Since we do time-based rather than feature-based releases, the major
> > version number shouldn't mean anything special anyway (e.g. big IR
> > changes or not), so 4.0?
> >
> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
> > a tuple after all.
> >
> > - Let's go for 4.0 now, and 5.0 after that. Then the
"dot"-releases in
> > between would correspond to minor version bumps, which would make
> > sense (and catch up with GCC!).
> >
> > - It's just a number, no big deal; flip a coin or something.
> >
> > What do you think?
> >
> > - Hans
> >
> >
> > [1].
> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160613/d50365f4/attachment.html>

> On Jun 13, 2016, at 5:56 PM, Saleem Abdulrasool <compnerd at
compnerd.org> wrote:
> 
> On Mon, Jun 13, 2016 at 5:01 PM, Mehdi Amini via lldb-dev <lldb-dev at
lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
> 
> > On Jun 13, 2016, at 4:54 PM, Hans Wennborg <hans at chromium.org
<mailto:hans at chromium.org>> wrote:
> >
> > Breaking this out into a separate thread since it's kind of a
separate
> > issue, and to make sure people see it.
> 
> Thanks!
> 
> >
> > If you have opinions on this, please chime in. I'd like to collect
as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> 
> (basically repeating my point of the other thread here)
> Bumping the major version number without changing the bitcode compatibility
rule would mean dropping the current guarantee on this aspect. I doubt we want
to go this route without a good reason.
> 
> Completely agree with you here: unless we have a reason to break backwards
compatibility at the bit code level for this release, I don't see a
compelling reason to bump the major version number to 4.0.  As such, I would
expect that the next release would be 3.10.
To clarify my point: I don't have a particular opinion about bumping the
major number for whatever other reason than breaking the compatibility, but
I'd probably suggest that we rewrite the compatibility policy to say
something like "The current LLVM version support loading any bitcode since
version 3.0".


-- 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160613/e6bc472c/attachment.html>

.
>
>
> To clarify my point: I don't have a particular opinion about bumping
the
major number for whatever other reason than breaking the compatibility, but
I'd probably suggest that we rewrite the compatibility policy to say
something like "The current LLVM version support loading any bitcode since
version 3.0".

But then what is the promise for how long 3.0 is supported? We really
should not imply that it will always be supported.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/a04b79ae/attachment.html>