<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 4 Jan 2018, at 23:31, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="gmail_quote">On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dimitry@andric.com" target="_blank" class="">dimitry@andric.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><span class="">On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">><br class="">> I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch.<br class="">><br class="">> Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4 months from now. Since some people use and release snapshots of clang from trunk (e.g. the Android NDK), it'd be helpful to be able to more reliably distinguish this.<br class="">><br class="">> This is both confusing in general, and means that if you're writing an #if checking the version (which of course ought to be avoided when possible, but is sometimes the best answer), it is more difficult than it needs to be to do the right thing.<br class="">><br class="">> E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug.<br class="">> #if __clang_major__ >= 7<br class="">> // Do something which was buggy before Clang 7.<br class="">> #endif<br class=""><br class=""></span>Yes, this is often done in the FreeBSD ports system, sometimes using the major version in the source, but more often in Makefiles, where the X.Y.Z version is condensed to just 'XY', as shown in<span class="Apple-converted-space"> </span><a href="https://github.com/freebsd/freebsd-ports/blob/master/lang/v8/Makefile#L36" rel="noreferrer" target="_blank" class="">https://github.com/freebsd/<wbr class="">freebsd-ports/blob/master/<wbr class="">lang/v8/Makefile#L36</a><span class="Apple-converted-space"> </span>:<br class=""><br class="">.if ${COMPILER_TYPE} == clang<br class="">CXXFLAGS+= -Wno-nested-anon-types -Wno-unused-function -Wno-unused-private-field<br class="">MAKE_ENV+= LINK=clang++<br class="">.if ${COMPILER_VERSION} >= 34<br class="">CXXFLAGS+= -Wno-unused-const-variable<br class="">.if ${COMPILER_VERSION} >= 35<br class="">CXXFLAGS+= -Wno-tautological-undefined-<wbr class="">compare<br class="">.if ${COMPILER_VERSION} >= 36<br class="">CXXFLAGS+= -Wno-unused-local-typedef<br class="">.endif<br class="">.endif<br class="">.endif<br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class="">That seems a very unfortunate scheme, especially considering the differing definition of the same-named variable in FreeBSD core's makefiles:</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class=""><a href="https://github.com/freebsd/freebsd/blob/d67d8724ce34e69801d9018e6bf76afed2ca3841/share/mk/bsd.README" class="">https://github.com/freebsd/freebsd/blob/d67d8724ce34e69801d9018e6bf76afed2ca3841/share/mk/bsd.README</a></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class="">"""</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class="">COMPILER_VERSION<br class=""></div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre;" class=""> </span>A numeric constant equal to:</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre;" class=""> </span> major * 10000 + minor * 100 + tiny</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre;" class=""> </span>for the compiler's self-reported version.</div><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: small; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; background-color: rgb(255, 255, 255);" class="">"""</div></div></div></div></blockquote><div><br class=""></div><div>Yes indeed, it is an unfortunate difference between the base system and the ports system. I feel that the major * 10000 + minor * 100 + tiny constant is more useful, but the maintainers of the ports system decided to use a shorter constant.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="gmail_quote"><div class="">I don't think that's a good reason to not use X.99 for clang versions, however -- the FreeBSD makefile can easily translate that to X9 if it likes, or, change their definition.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><span class="">> I see a couple alternatives for improving this:<br class="">><br class="">> 1. Change the way we version trunk.<br class="">><br class="">> After creating release branch for X.0, change trunk to version X.99 instead of (X+1).0. Thus, trunk would always have a .99 minor release. The release branch would be incremented from X.99 to (X+1).0 upon creation.<br class="">><br class="">> 6.99.0-------7.99.0-----------<wbr class="">-----8.99.0------...<br class="">> \-7.0.0----7.0.1 \-8.0.0----8.0.1<br class=""><br class=""></span>Probably 6.9, 7.9 and such would be enough, since 7.1 and 7.2 won't ever appear in the recent "new versioning scheme", and even older versions never reached past the .9 second level version?<br class=""></blockquote><div class=""><br class=""></div><div class="">Perhaps so, but I greatly prefer the implication that "99" has that it's not a real version, which "9" is much less suggestive of.</div></div></div></blockquote><div><br class=""></div><div>Yes, that is certainly a good reason. The second scheme would be similar in this respect, e.g. if the minor version number is 0, it is always trunk version.</div><div><br class=""></div><div>-Dimitry</div><div><br class=""></div></div></body></html>