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

[David Blaikie via llvm-dev]

On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> ----- Original Message -----
> > From: "Hans Wennborg via cfe-dev" <cfe-dev at lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" <
> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at lists.llvm.org>,
> > "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev at lists.llvm.org>
> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul Robinson" <
> Paul_Robinson at playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > Breaking this out into a separate thread since it's kind of a
> > separate
> > issue, and to make sure people see it.
> >
> > 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.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a natural
> forcing function here: opaque pointer types. I think we should increment
> the major version number when opaque pointer types are here, as it will be
> a major breaking change, and then we'll have a version 4.0. Until then,
> unless something else breaking comes up, 3.10 sounds fine to me.
>

At least naively, I'd expect opaque pointer types to be backwards
compatible (ie: we can load old bitcode and just strip all the pointer
types and bitcasts). But perhaps it still meets the bar of a big change &
may be worth shedding all the backwards compatibility weight sooner rather
than later after the change, for sure.

(as to the main issue - yeah, I tend to agree with you/Mehdi, etc - go to
3.10 and so on, until we decide it's worth breaking back-compat - do we
need to update any wording about our back-compat guarantee that says we
won't do the inverse (4.3 -> 5.0 because we decide we have another breaking
change), though? Since we'll demonstrated that primary version bumps aren't
on a strict ~5 year cycle anymore - probably don't need to do anything, but
just a thought)

- Dave


>
>  -Hal
>
> >
> > - 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
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160613/b13712a1/attachment.html>