On Tue, Jun 28, 2016 at 5:22 PM, Duncan P. N. Exon Smith <dexonsm...@apple.com> wrote: > >> On 2016-Jun-28, at 16:22, Hans Wennborg via cfe-dev <cfe-...@lists.llvm.org> >> wrote: >> >> On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev >> <llvm-...@lists.llvm.org> wrote: >>> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev >>> <openmp-...@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 >>> possible outcome. >>> >>> Chris has said it is because he thinks we'll never change the "3”, >>> >>> >>> Yes, that is one reason. >>> >>> but I don't understand why 3.10 is worse than 3.9 was in that respect. >>> >>> >>> Because it breaks from the established pattern we have, and means that we >>> never get to 4. >>> >>> I happen to agree that we'll never change the "3", but I don't think this >>> makes 3.10 a particularly bad choice. >>> >>> >>> If you agree that we’ll never change the 3, then you are staying that you >>> believe it is ok for the version number to be meaningless. In that case, I >>> can’t see why you’d object to a policy change. >>> >>> I believe that the version number is important. Which is why I care so much >>> about it :-) >>> >>> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion >>> to encode into the version number - from a historical perspective, we only >>> used that as rationale because it happened to align well for the 1.9 to 2.0 >>> conversion and then used it as an excuse to shed some legacy in the 3.0 >>> timeframe. >>> >>> Given that, and given that we have a time based release, we should either >>> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning >>> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42). >> >> Since there seems to be some kind of rough consensus forming around >> the idea of moving towards a model with x.y version numbers where we >> increment x every six months and y for the "dot" releases in between, >> let's take it to a code review: >> >> http://reviews.llvm.org/D21821 >> >> What angles am I missing? I'm sure this can break the world in >> interesting ways. (It looks like Clang's cmake config is already set >> up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL). > > For one thing, I can't find the patch on the mailing list ;). I'm guessing > you missed adding llvm-commits as a subscriber?
Good point :-) Added it now. _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
