similar to: What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

On Tue, Jun 21, 2016 at 7:56 AM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >>> Let me clarify. What I’m trying to say is that: > >> > >>> a) LLVM has a time-based release cycle, not a schedule-based one. As >

On Mon, 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. > > 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 also support Chris's position of 4.0, 4.1 etc. I don't think "majorness" is that important, and we can sort out the bit code compatibility story some other way. Sent from phone On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org> wrote: >

I also believe this is the simplest versioning scheme*. It eliminates all future debates on this topic (e.g, when to bump major version etc) and solves the problem once and for all -- which is another plus :) *) similar suggestions a) start from 4, increase by 1; b) start from 40, increase by 1. Date based scheme is also a variant of it. David On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner

On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev < cfe-dev at lists.llvm.org> wrote: > I also believe this is the simplest versioning scheme*. It eliminates all > future debates on this topic (e.g, when to bump major version etc) and > solves the problem once and for all -- which is another plus :) > Except that we'll have to keep dealing with people who are

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev <cfe-dev at lists.llvm.org> wrote: > On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev > <cfe-dev at lists.llvm.org> wrote: >> >> I also believe this is the simplest versioning scheme*. It eliminates all >> future debates on this topic (e.g, when to bump major version etc) and >>

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

> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> 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

Bug in cmake (or more likely the makefile?), pure and simple. Version numbers aren't strings, and they aren't floating point numbers, they are a series of integers separated by dots. I can't think of a project where interpreting version numbers that way won't work. On Wed, Jun 15, 2016 at 7:21 AM, Cristianno Martins via llvm-dev < llvm-dev at lists.llvm.org> wrote: >

First, kudos on the ThinLTO results reported in your blog post — they’re impressive and the system sounds really well engineered. I’m starting to try it out on a large piece of software and I’d like to make sure I know what to expect. The blog said it will be available in clang-3.9 but both clang-3.8 and trunk seem to have some degree of support for it. What is the status of ThinLTO in 3.8

> 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

> 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

On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: > That's what concerns me about going to the scheme Richard and Rafael > suggested, of bumping the major version each time: we'd release 4.0, > and would Tom's dot-release then be 4.1? That would be confusing to > those who are used to our current scheme. Chris suggested going

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 >

On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner <clattner at apple.com> wrote: > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> That's what concerns me about going to the scheme Richard and Rafael >> suggested, of bumping the major version each time: we'd release 4.0, >> and would Tom's dot-release then be

> On Jul 22, 2016, at 12:36 PM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Vikram, > > Thanks! > > I'm not sure what part got committed in the 3.8 timeframe - it looks like that was released back in March? 3.8 was branched in early January though. It has some of the work-in-progress for ThinLTO, it “could” work in simple cases I

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

>> The promise just says that 4.0 *will* read 3.X and 4.1 might. > > > 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. >

On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev > <lldb-dev at lists.llvm.org> wrote: >> >> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner <clattner at apple.com> wrote: >> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev >> > <llvm-dev at

On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev > <openmp-dev at lists.llvm.org> wrote: >> >> I think I agree with Chris with 3.10 being the worst possible outcome. > > > I'd be interested to understand why you or Chris thing 3.10 is the worst