<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 20, 2018 at 1:35 AM Hans Wennborg via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" 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">On Wed, Dec 19, 2018 at 8:05 PM David Jones via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> On Wed, Dec 19, 2018, 13:21 David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> wrote:<br>
>> I agree that -git or -dev could be misleading.  I also agree that we may<br>
>> not need this tag at all.<br>
><br>
><br>
> Strictly speaking, we don't *need* to switch to git, either. ;-)<br>
<br>
What I meant was that I don't see why we need this in order to switch<br>
to git. Getting nice git-describe results seems nice, but is it<br>
necessary? I've never used it myself, so I'm not that familiar with<br>
it.<br>
<br>
If we just want the ability to refer to trunk commits by number,<br>
couldn't we just tag the initial commit as "genesis" and git-describe<br>
against that?<br>
<br>
> Tagging the split point is semantically the wrong thing, though:<br>
<br>
It can't be semantically wrong if the tag correctly describes the<br>
commit it's applied to.<br>
<br>
That's my objection to tagging the version bump with things like<br>
"8.0.0-dev": the name implies that the commit is the development<br>
version of 8.0.0, which it's not.<br>
<br>
If we do tag the version bump, I think the name has to be something<br>
like "8.0.0-base" or "8.0.0-first", to correctly describe the commit<br>
it's tagging.<br>
<br>
> if you `git describe` the last commit before the branch for release ${N} (i.e., the last commit of N), the descriptor will be ${N+1} (or whatever tag was applied). The version bump commit will then be "${N+1}-1", meaning the second commit of the N+1 release (with commit hashes as appropriate).<br>
<br>
I'm having trouble following the maths here, but if we tag the<br>
branchpoint, say "7.0.0-branchpoint", then the commits on trunk after<br>
that, i.e. the development of 8, will be described as "n patches after<br>
7.0.0-branchpoint" which seems entirely correct to me: version 8 is<br>
stuff landed after the branchpoint for 7".<br>
<br>
> An easy way to reason about this is that the version bump tag should only be reachable from the release branch for that version. So if the 8.0 bump is reachable from the 7.x release branch, that's going to result in `git describe` attributing commits with the wrong version.<br>
<br>
I don't understand this part. Why would the 8.0 bump be reachable from<br>
the 7.x release branch? The version bump happens after the branch is<br>
created.<br>
<br>
<br>
Anyway, all I'm saying is that if we add tags, the name must match<br>
what the commit does. Tagging the version bump with "8.0.0svn" or<br>
"8.0.0-dev" or similar doesn't do that.<br></blockquote><div><br></div><div>I see the "tagging" not much differently than the commit where we change the version number in the CMakefile, so I would tentatively tag this bump for consistency?</div><div><br></div><div>-- </div><div>Mehdi</div></div></div>