[llvm-dev] New LLVM git repository conversion prototype

Tue Dec 18 16:12:52 PST 2018

On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote:
> On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote:
> 
>     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"
> 
> 
> Here's my proposal:
> - Release branches will be named: release/3.5.x (for old version numbering scheme), release/7.x (for new).
> - The tags for release branches will be named v8.0.0 (for final), and v8.0.0-rc1 for release candidates.
> - 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.
> 

There haven't been many more responses in the last few days, so can we
try to come to some kind of consensus here?

I've skimmed through the most recent replies and there 3 things we need to
name:

1. Release tags.  There were a lot of small variation on the tag names for releases,
but it seems like the preferences was to use the llvm.org prefix,
so I'm going to propose using tag names like:

llvm.org-8.0.0
llvm.org-8.0.0-rc1

Any strong objections to this?

2. Tags for commits in the master branch that bump the release version.

Most of the discussion about this so far has been on what to put after
the version number (e.g. v8.0.0-dev, v8.0.0-base, v8.0.0-branchpoint).
Other things to consider about this tag is that it might be used in
a git describe alias to identify commits, so it would be helpful if
it was short.

One idea I had after reading through all the responses was to use the
-git suffix on the tags. e.g. v8.0.0-git.  It's short and it's clear
that you are getting something that isn't an official release.  It
also is similar to the 8.0.0svn version number that we currently use
to indicate a non-released version.  Which of these 4 options(
dev, base, branchpoint, git) do people prefer?

3. Branch names:

It seems like there is some preference to include the minor version number
in the release branch, so any strong objections to using
release/7.0.x as the branch naming?

My last question is what will it take to move forward with the monorepo?
Do we just need to settle on the branch names or do we really need to
have a decision on all of these?  It would be great if we could get
the official monorepo up before the end of the year.

-Tom

> On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <mail at justinbogner.com <mailto:mail at justinbogner.com>> wrote:
> 
>     As a bit of a side note, v8.0.0 is probably too brief - I expect v*
>     could easily match some arbitrary tag that starts with the letter v too
>     easily. I don't have strong opinions about the particular name, but
>     something like llvm-8.0.0 or llvm.org-v8.0.0 would be better.
> 
> 
> I don't feel terribly strongly about whether to use "llvm-8.0.0" or "v8.0.0".
> 
> 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.
> 
> 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.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 