<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 19, 2018 at 1:21 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 1:12 AM Tom Stellard via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote:<br>
> > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <<a href="mailto:Jeremy.Lakeman@gmail.com" target="_blank">Jeremy.Lakeman@gmail.com</a> <mailto:<a href="mailto:Jeremy.Lakeman@gmail.com" target="_blank">Jeremy.Lakeman@gmail.com</a>>> wrote:<br>
> ><br>
> >     Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The hyphen indicating that this is a pre-release version coming before "v8.0.0"<br>
> ><br>
> ><br>
> > Here's my proposal:<br>
> > - Release branches will be named: release/3.5.x (for old version numbering scheme), release/7.x (for new).<br>
> > - The tags for release branches will be named v8.0.0 (for final), and v8.0.0-rc1 for release candidates.<br>
> > - Tags on the master branch (which will be created at commits modifying the version file after branch creation, ala r338537) will be named v8.0.0-dev.<br>
> ><br>
><br>
> There haven't been many more responses in the last few days, so can we<br>
> try to come to some kind of consensus here?<br>
><br>
> I've skimmed through the most recent replies and there 3 things we need to<br>
> name:<br>
><br>
> 1. Release tags.  There were a lot of small variation on the tag names for releases,<br>
> but it seems like the preferences was to use the <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a> prefix,<br>
> so I'm going to propose using tag names like:<br>
><br>
> llvm.org-8.0.0<br>
> llvm.org-8.0.0-rc1<br>
><br>
> Any strong objections to this?<br>
<br>
Maybe llvm.org-8.0.0-final for the final one, similar to what we do<br>
currently? Otherwise sgtm.<br>
<br>
> 2. Tags for commits in the master branch that bump the release version.<br>
<br>
I may have missed something in the thread, but do we actually *need* this?<br></blockquote><div><br></div><div>That enables `git describe` to return the right version name while in master (and indicates the number of commits since the branching point)</div><div><br></div><div>See David's email here: <a href="http://lists.llvm.org/pipermail/llvm-dev/2018-November/127822.html">http://lists.llvm.org/pipermail/llvm-dev/2018-November/127822.html</a></div><div><br></div><div>-- </div><div>Mehdi</div><div> </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">
<br>
> Most of the discussion about this so far has been on what to put after<br>
> the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint).<br>
> Other things to consider about this tag is that it might be used in<br>
> a git describe alias to identify commits, so it would be helpful if<br>
> it was short.<br>
><br>
> One idea I had after reading through all the responses was to use the<br>
> -git suffix on the tags. e.g. v8.0.0-git.  It's short and it's clear<br>
> that you are getting something that isn't an official release.  It<br>
> also is similar to the 8.0.0svn version number that we currently use<br>
> to indicate a non-released version.  Which of these 4 options(<br>
> dev, base, branchpoint, git) do people prefer?<br>
<br>
I think it's important that a tag actually describes what the commit<br>
is. "v8.0.0-dev" or "-git" sounds like it's the development version of<br>
8.0.0, which it's not -- as proposed, it's really the first commit<br>
after 7.0.0 was branched.<br>
<br>
If we really need a tag for this, and I'm not sure we do, I think we<br>
should instead tag the commit that we branch from, i.e.<br>
v7.0.0-branchpoint. If brevity is important, it could be just "v7-bp".<br>
<br>
I propose that we don't block on having these.<br>
<br>
<br>
> 3. Branch names:<br>
><br>
> It seems like there is some preference to include the minor version number<br>
> in the release branch, so any strong objections to using<br>
> release/7.0.x as the branch naming?<br>
<br>
That sgtm.<br>
<br>
Thanks,<br>
Hans<br>
<br>
<br>
<br>
<br>
> > On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a> <mailto:<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>>> wrote:<br>
> ><br>
> >     As a bit of a side note, v8.0.0 is probably too brief - I expect v*<br>
> >     could easily match some arbitrary tag that starts with the letter v too<br>
> >     easily. I don't have strong opinions about the particular name, but<br>
> >     something like llvm-8.0.0 or llvm.org-v8.0.0 would be better.<br>
> ><br>
> ><br>
> > I don't feel terribly strongly about whether to use "llvm-8.0.0" or "v8.0.0".<br>
> ><br>
> > The "v8.0.0" style seems to be very widely used, so that'd still be my inclination, barring a good reason why we shouldn't. The other scheme I've seen commonly is actually just the raw version, e.g. "8.0.0" without any prefix at all.<br>
> ><br>
> > I'll note that there is at least one minor advantage to using one of "v8.0.0" or "8.0.0". Github can make download tarballs/zipfiles from release tags, and when doing so, will name the file "$repository-$name.zip" (if you're downloading a tag or branch), or "$repository-$commithash.zip" otherwise. For tag names, it also strips "v" prefix in front of a version number, if you had one.  So, with either of the usual schemes, we'd get an automatically-generated filename of "llvm-8.0.0.zip". Instead of, say, "llvm-llvm-8.0.0.zip" if we were to go with a tag named "llvm-8.0.0". That said -- the LLVM project probably isn't going to use those for our official release distributions, so I think that advantage doesn't really matter.<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/llvm-dev</a><br>
> ><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/llvm-dev</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div>