>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@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-...@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 >> <cristiannomart...@hotmail.com> >> >> 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" <cfe-...@lists.llvm.org> >>>>>> > To: "llvm-dev" <llvm-...@lists.llvm.org>, "cfe-dev" < >>>>>> cfe-...@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>, >>>>>> > "openmp-dev (openmp-...@lists.llvm.org)" <openmp-...@lists.llvm.org >>>>>> > >>>>>> > Cc: "r jordans" <r.jord...@tue.nl>, "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 >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
