Bruce Hoult via llvm-dev
2016-Jun-16 09:46 UTC
[llvm-dev] [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
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:> 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 > <cristiannomartins at hotmail.com> > > On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < >> cfe-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < >>> cfe-dev at lists.llvm.org> wrote: >>> >>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < >>>> lldb-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. >>>>> >>>> >>>> +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-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>> >>> _______________________________________________ >>> cfe-dev mailing list >>> cfe-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/acb588fc/attachment.html>
Adrian McCarthy via llvm-dev
2016-Jun-16 17:02 UTC
[llvm-dev] [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
>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. TeX (asymptotically approaches pi), METAFONT (asymptotically approaches e), Opera (decimal number). Sayeth Wikipedia <https://en.wikipedia.org/wiki/Software_versioning#Incrementing_sequences>:> Most free and open-source software packages, including MediaWiki, treat > versions as a series of individual numbers, separated by periods, with a > progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, > 1.11.2, and so on. On the other hand, some software packages identify > releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc.Note that 81 > 8, so those examples would still work. But 3.10 is easy to misinterpret as 3.1. On Thu, Jun 16, 2016 at 2:46 AM, Bruce Hoult via lldb-dev < lldb-dev at lists.llvm.org> wrote:> 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: > >> 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 >> <cristiannomartins at hotmail.com> >> >> On Tue, Jun 14, 2016 at 10:48 PM, Sean Silva via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev < >>> cfe-dev at lists.llvm.org> wrote: >>> >>>> >>>> >>>> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev < >>>> cfe-dev at lists.llvm.org> wrote: >>>> >>>>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < >>>>> lldb-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. >>>>>> >>>>> >>>>> +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-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>>> >>>> >>>> _______________________________________________ >>>> cfe-dev mailing list >>>> cfe-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >>>> >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ > lldb-dev mailing list > lldb-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160616/945144ea/attachment.html>
Joerg Sonnenberger via llvm-dev
2016-Jun-16 20:00 UTC
[llvm-dev] [cfe-dev] [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)
On Thu, Jun 16, 2016 at 10:02:52AM -0700, Adrian McCarthy via cfe-dev wrote:> > Most free and open-source software packages, including MediaWiki, treat > > versions as a series of individual numbers, separated by periods, with a > > progression such as 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, > > 1.11.2, and so on. On the other hand, some software packages identify > > releases by decimal numbers: 1.7, 1.8, 1.81, 1.82, 1.9, etc. > > > Note that 81 > 8, so those examples would still work. But 3.10 is easy to > misinterpret as 3.1.The only environment I know where such an interpreation is popular is CPAN. Everyone else effectively uses Dewey-style interpretation. So yes, some crappy software might mishandle 3.10 by using patterns like 3.1* and not 3.1.*, but I don't believe catering to broken software is very useful. Joerg