[llvm-dev] New LLVM git repository conversion prototype

[Tom Stellard via llvm-dev]

On 12/18/2018 08:01 PM, Bruce Hoult wrote:
> On Tue, Dec 18, 2018 at 4:13 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
>     There haven't been many more responses in the last few days, so can we
>     try to come to some kind of consensus here?
> 
> 
> Can we please just get the repo up? I've been waiting two months since it was promised, told bosses I'd have a permanent git repo of llvm up where the hashes were never going to change under people again etc.
> 
> The remaining discussion seems to be about tags and branch names. Neither of those changes hashes of commits or trees or blobs. Both can be fiddled with after the fact without affecting anything else.
> 

Yes, I agree with you that we need to move forward.  I think enough people have given
input that I'm personally fine if James just wants to make a final decision based
on the responses so far.

> 
>     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 <http://llvm.org> prefix,
>     so I'm going to propose using tag names like:
> 
>     llvm.org-8.0.0
>     llvm.org-8.0.0-rc1
> 
> 
> Fine.
>  
> 
>     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?
> 
> 
> Any. Even keeping 8.0.0svn would make some tools simpler.
> 
>  
> 
>     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?
> 
> 
> Actually, I do object to that.
> 
> A release branch is something that doesn't get any new features, only bug/security fixes. When you start along the release/7.0 branch you will find tags for 7.0.1, 7.0.2 etc but it remains the 7.0 *branch*.
> 

Are you suggesting release/7.0 instead of release/7.0.x?  If so, I agree.

> Also: is that .0 *ever* again going to be incremented? Not as far as I know. It probably should have been dropped at release/4
> 

I am planning to do a 7.1.0 release due to a bug fix that breaks the ABI.

-Tom

> Also: I haven't seen anyone bike-shedding whether the tags should be annotated tags or lightweight tags. I don't think that's because everyone knows the difference and implicitly agrees on the answer :-) :-)
> 
> The answer (in any public repo, really) should be annotated tags, so they include the committer name and the date.
>