> On Jun 28, 2016, at 4:26 PM, Duncan P. N. Exon Smith via llvm-dev > <llvm-...@lists.llvm.org> wrote: > > >> On 2016-Jun-28, at 13:17, Richard Smith via lldb-dev >> <lldb-dev@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. >> >> Personally: I think it would be a bad outcome, because if we go to 3.10, I >> do not see when we would ever transition to 4.0. What change would be "large >> enough" to classify as a new major version of all of LLVM? Given that we are >> (presumably) going to have a "sliding window" support story for LLVM IR >> changes, and even LLVM IR changes are irrelevant to a significant number of >> LLVM subprojects (all of which share the same versioning scheme), it's not >> clear to me what would justify this. >> >>> Chris has said it is because he thinks we'll never change the "3", but I >>> don't understand why 3.10 is worse than 3.9 was in that respect. I happen >>> to agree that we'll never change the "3", but I don't think this makes 3.10 >>> a particularly bad choice. >> >> We've historically gone from x.9 to x+1.0, so this sets precedent, and we >> seem to have the energy and motivation to discuss and possibly change our >> version numbering scheme right now. For me, it's just a question of "if not >> now, then when?". >> >>> I'm seeing pretty much zero support for continuing to have a major/minor >>> split. As such, I pretty strongly suggest that as a community we move to a >>> single integer that increments every (time based) release, and a .N that >>> increments with every patch release off of that branch. GCC and numerous >>> other projects work this way. >>> >>> I actually don't care at all what the number is: 4 or 40 seem fine. >>> >>> 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 agree with Richard. While I don't have a strong opinion about 3.10.x vs. > 4.x vs. 4.0.x (assuming we document our *actual* bitcode compatibility > promise), I think both 10.x and 40.x are actively confusing.
I can see an argument for 10.x: let’s just drop the leading "3.” And continue to number from where we are, i.e. 10. — Mehdi _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
