On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev <lldb-dev@lists.llvm.org> wrote: >> If 4 seems too confusing, and 40 seems too extreme, how about 10. >> Seriously. It seems exactly as good as any other integer to start counting >> rationally, and won't confuse people by looking like a 4.0 release. > > > I think going to 10 or 40 is likely to be confusing, because there'll be two > different ways to refer to the same version (people will say 3.10 when > referring to version 10, or 38 when referring to version 3.8, respectively). > This happened to Java in the version 1.6 / version 6 numbering transition. > > In order to preserve numbering continuity and minimize confusion, if we go > from three-component versions (major.minor.patch) to two-component versions > (major.patch), I would suggest we go from x.y.z to x+1.0. (This is also > consistent with how GCC handled the transition.)
I haven't followed how this worked out for GCC, but I worry that if we go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will get confused when we ship 4.1 as a "dot" release instead of a major release like we've used to. There's also the question of how to practically go from a 3-tuple to a 2-tuple. Should we drop it from the version string and dir names in Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I see GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to do it? Cheers, Hans _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev