llvm dev - Dec 2018 - New LLVM git repository conversion prototype

James Y Knight via llvm-dev <llvm-dev at lists.llvm.org>
writes:
> On Fri, Nov 16, 2018 at 5:46 PM David Jones <dlj at google.com>
wrote:
>> $ git tag -m 'Begin development of 8.0.0.' '8.0.0svn'
63297479398
>>
>> Then, `git describe` can give a useful result that would be stable(-ish
>> [*]):
>>
>> $ git describe --match=\*svn
>> 8.0.0svn-7878-gfdb08034fd8
>>
>> ([*] Subject to the normal caveat for git-describe: the trailing short
>> hash may become non-unique over time. This is mentioned in the git
help.)
>>
>> Again, I think these tags could probably be added later, but it would
be
>> nice to have a single source of truth (especially since the tag
annotation
>> is itself a commit).
>>
>> I think we could also probably come up with better than than
'8.0.0svn';
>> although whatever the choice, they probably need to be suitable for
>> --match, because...
>>
>
> We could name tags named something like: "v8.0dev" (for trunk
tag),
> "v8.0.0rc1" (after making a branch and updating the version
numbers in the
> branch), "v8.0.0" (for the final release from the branch). And,
use
> --match="v*" in the describe output. I think this basically
obviates the
> need for request #2.
This seems like a very good thing to do, and if it wasn't obvious, this
is also something we should plan to do going forward once we start
branching our releases in git directly.

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.

On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <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.

On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181212/0eb3a4c6/attachment-0001.html>

James Y Knight <jyknight at google.com> writes:
> On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <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.
>
> On Fri, Nov 16, 2018 at 10:10 PM Justin Bogner <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.
There are two reasons I can think of to use a prefix like llvm or
llvm.org here:

1. Tools that can filter based on globs of tags will be more reliable -
   globs like llvm-* or llvm-*dev are pretty unlikely to hit arbitrary
   other tags, whereas v* is less clear and I don't even know how you'd
   glob for a pure number.

2. There are *a lot* of downstream projects based on llvm, and they're
   all likely to adopt the monorepo and add their own stuff to it.
   Namespacing the official tags gives them an obvious model for how to
   do their own tags and makes it easy to tell what a tag means at a
   glance.

That said, it's easy enough for me to re-tag all of the v* tags in with
llvm.org-* in my downstream, so I think this boils down to aesthetics.
> 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.

On Thu, Dec 13, 2018 at 5:54 AM James Y Knight via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <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.
I'm not sure about the part about tagging the master branch.

In your example, if someone checks out v8.0.0-dev, they would not get
the latest version of 8.0.0-dev, i.e. master, but the *first* commit,
which seems odd.

I suppose we could call it v8.0.0-base or something like that, but do
we really need this?

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
>