Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < lldb-dev@lists.llvm.org> wrote: > - Original Message - > > From: "Hans Wennborg via cfe-dev" > > To: "llvm-dev" , "cfe-dev" < > cfe-...@lists.llvm.org>, "LLDB Dev" , > > "openmp-dev (openmp-...@lists.llvm.org)" > > Cc: "r jordans" , "Paul Robinson" < > paul_robin...@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. > +1, complete agreement. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev < cfe-...@lists.llvm.org> wrote: > - Original Message - > > From: "Hans Wennborg via cfe-dev" > > To: "llvm-dev" , "cfe-dev" < > cfe-...@lists.llvm.org>, "LLDB Dev" , > > "openmp-dev (openmp-...@lists.llvm.org)" > > Cc: "r jordans" , "Paul Robinson" < > paul_robin...@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. > We're talking about version numbers for the entire LLVM project here, which encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is utterly irrelevant. I'm not convinced that tying version numbers to backwards-incompatible changes to IR is reasonable any more, and it doesn't seem hard to explicitly document the oldest version with which we are compatible (in fact, we need to do that regardless, whether we say it's "the same major version" or "everything since 3.0" or whatever else). Given that our releases are time-based rather than feature-based, I don't see a distinct major / minor version being anything other than arbitrary, so I'd suggest we take 4.0 as our next release, 4.1 as the first patch release on that, 5.0 as the next release after that, and so on. -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-...@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-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
. > > > 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
>> 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. > +1, complete agreement. Agree -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 28127] New: lldb-server broken when LLVM_LINK_LLVM_DYLIB=ON
https://llvm.org/bugs/show_bug.cgi?id=28127 Bug ID: 28127 Summary: lldb-server broken when LLVM_LINK_LLVM_DYLIB=ON Product: lldb Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: pa...@sifflez.org CC: llvm-b...@lists.llvm.org Classification: Unclassified Affects snapshot_3.9~svn272283. Building lldb with LLVM_LINK_LLVM_DYLIB=ON results in a non-working lldb-server. llvm-toolchain-snapshot_3.9~svn272283/build-llvm$ bin/lldb-server : CommandLine Error: Option 'print-summary-global-ids' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options As explained in #22952, this seems to be due to a CommandLine name collision. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> - Original Message - >> > From: "Hans Wennborg via cfe-dev" >> > To: "llvm-dev" , "cfe-dev" < >> cfe-...@lists.llvm.org>, "LLDB Dev" , >> > "openmp-dev (openmp-...@lists.llvm.org)" >> > Cc: "r jordans" , "Paul Robinson" < >> paul_robin...@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. >> > > +1, complete agreement. > While I'm not sure opaque pointer types are going to increment versions I'm also in agreement that 3.10 is the right way to go. -eric > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Thank you for raising this question! I think 3.10 makes sense until we have a strong enough breaking change (in anything, not just LLVM bit code) to warrant bumping to 4.0. ~Aaron On Mon, Jun 13, 2016 at 7:54 PM, Hans Wennborg via cfe-dev 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'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? > > - 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-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Tue, Jun 14, 2016 at 1:32 AM Richard Smith via cfe-dev < cfe-...@lists.llvm.org> wrote: > On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> - Original Message - >> > From: "Hans Wennborg via cfe-dev" >> > To: "llvm-dev" , "cfe-dev" < >> cfe-...@lists.llvm.org>, "LLDB Dev" , >> > "openmp-dev (openmp-...@lists.llvm.org)" >> > Cc: "r jordans" , "Paul Robinson" < >> paul_robin...@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. >> > > We're talking about version numbers for the entire LLVM project here, > which encompasses a lot more than LLVM IR, and for many parts of which LLVM > IR is utterly irrelevant. I'm not convinced that tying version numbers to > backwards-incompatible changes to IR is reasonable any more, and it doesn't > seem hard to explicitly document the oldest version with which we are > compatible (in fact, we need to do that regardless, whether we say it's > "the same major version" or "everything since 3.0" or whatever else). > > Given that our releases are time-based rather than feature-based, I don't > see a distinct major / minor version being anything other than arbitrary, > so I'd suggest we take 4.0 as our next release, 4.1 as the first patch > release on that, 5.0 as the next release after that, and so on. > This seems oddly familiar. So, one point is that LLVM's IR compatibility impacts more projects than many other things do: - Clang generates bitcode with '-flto' and cares about compatibility with it. - LLD imports bitcode for LTO and cares about compatibility with it. Certainly, LLDB and libc++ are both ... substantially less impacted. All that said, I'm not opposed to a dramatically simpler version numbering scheme which just counts cycles provided we also establish some strategy for marking the bitcode compatibility requirements. But I also don't see it as an important change to make right now. -Chandler > -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-...@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-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < cfe-...@lists.llvm.org> wrote: > > > On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> - Original Message - >>> > From: "Hans Wennborg via cfe-dev" >>> > To: "llvm-dev" , "cfe-dev" < >>> cfe-...@lists.llvm.org>, "LLDB Dev" , >>> > "openmp-dev (openmp-...@lists.llvm.org)" >>> > Cc: "r jordans" , "Paul Robinson" < >>> paul_robin...@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. >>> >> >> +1, complete agreement. >> > > While I'm not sure opaque pointer types are going to increment versions > I'm also in agreement that 3.10 is the right way to go. > +1 -- Sean Silva > > -eric > > >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> > > ___ > cfe-dev mailing list > cfe-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
Hello there, First, I would like to say that I don't have any strong opinions on this matter: as mostly an user of LLVM, my basic concern is for me to be able to identify which version is the newest and configure it as easily as possible. That being said, I have a question about LLVM's versioning strategy: is it possible for other tools (including the ones LLVM depend on) to become broke or annoyingly buggy just because a bad versioning scheme was put in place? Just to give some context to this question, I've been using OS X for a while, and I confess I was pretty annoyed when OS X 10.9 was followed by OS X 10.10. Not at first, no: I didn't realize this would have any impact on my workspace until I had to compile some code, and CMake kept stopping just because it recognized that I was using an older version of the OS (emphasis on *older*). It is funny when you realize that 10.10 should actually be interpreted as less than 10.9, and CMake was falling for it, which was a wrong behavior of the tool, I admit, but the weird OS versioning scheme was the main cause of this issue. Of course this problem can be easily arranged by setting up some extra environment variables to tell CMake to target OS X 10.9 instead, but that was a very irritating behavior and only happened because a bunch of people (from CMake, and, then, from OS X's development team) thought comparing versions directly shouldn't be a problem. Besides, every one of these small details end up being some extra steps a new user need to follow to be able to use a tool, some of which could be easily avoided. I confess I didn't look into this matter after that, and still today, on OS X 10.11, I'm targeting version 10.9 on all my CMake runs on OS X -- thus, I don't know if this bug was fixed or not. However, as I'm starting to see a very similar pattern happening with LLVM on this thread, and I thought I could contribute with the discussion: did someone check if naming the next version "3.10" would have any impact on a production system? -- Cristianno Martins On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev < llvm-...@lists.llvm.org> wrote: > > > On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < > cfe-...@lists.llvm.org> wrote: > >> >> >> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < >> cfe-...@lists.llvm.org> wrote: >> >>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> - Original Message - > From: "Hans Wennborg via cfe-dev" > To: "llvm-dev" , "cfe-dev" < cfe-...@lists.llvm.org>, "LLDB Dev" , > "openmp-dev (openmp-...@lists.llvm.org)" > Cc: "r jordans" , "Paul Robinson" < paul_robin...@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. >>> >>> +1, complete agreement. >>> >> >> While I'm not sure opaque pointer types are going to increment versions >> I'm also in agreement that 3.10 is the right way to go. >> > > +1 > > -- Sean Silva > > >> >> -eric >> >> >>> ___ >>> cfe-dev mailing list >>> cfe-...@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> >> >> ___ >> cfe-dev mailing list >> cfe-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >> >> > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
