<div dir="ltr">I don't know about others, but I _don't_ want to be able to assign an ordering to unreleased versions at any higher granularity than which releases which they're in between.<div><br></div><div><div>Automatically assigning a consistently <span 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);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">ordered </span>version number to different trunk revisions is going to be difficult/impossible in general, what with branches, different version control systems, or even private branches in private repositories in different version control systems, so I don't really think it's a good idea to start going down that road.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 3, 2018 at 3:55 PM, Tom Stellard <span dir="ltr"><<a href="mailto:tstellar@redhat.com" target="_blank">tstellar@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/03/2018 09:24 AM, James Y Knight via llvm-dev wrote:<br>
> 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>
><br>
> 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>
><br>
> 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>
><br>
> E.g., a check like this will erroneously think that trunk, now, is Clang 7, and has fixed this hypothetical bug.<br>
> #if __clang_major__ >= 7<br>
> // Do something which was buggy before Clang 7.<br>
> #endif<br>
><br>
<br>
<br>
<br>
> I see a couple alternatives for improving this:<br>
><br>
> 1. Change the way we version trunk.<br>
><br>
> 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>
><br>
> 6.99.0-------7.99.0-----------<wbr>-----8.99.0------...<br>
>            \-7.0.0----7.0.1      \-8.0.0----8.0.1<br>
><br>
> 2. Change the minor version of the first release.<br>
><br>
> Leave trunk as X.0 as now, but on the release branch, increment the version to X.1.<br>
><br>
> 7.0.0--------8.0.0------------<wbr>-----9.0.0------...<br>
>            \-7.1.0----7.1.1      \-8.1.0----8.1.1<br>
><br>
> I'd marginally favor #2, because that's similar to how GCC is doing it now, but what do others think?<br>
><br>
<br>
<br>
</div></div>These proposed solutions only help distinguish between clang trunk and<br>
a clang release branch, but does not help to distinguish between today's<br>
trunk and a month from now trunk, which people using snapshots might<br>
care more about.<br>
<br>
<br>
What about adding a define like __clang_svn_revision__ instead?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Tom<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
</div></div></blockquote></div><br></div>