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

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 2:06 AM Justin Bogner <mail at justinbogner.com>
wrote:
> 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.
>

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

Hm, that's a very good point. My preference would be "llvm-8.0.0"
now.

Branches are namespaced to their origin repository by default, so renaming
some in a downstream fork is no issue.

But tags are, by default, global. So if you did rename tags in a fork, and
someone pulled from both repositories, they get the union of all the tags
without being able to tell the source, or potentially even conflicts
between them. Giving the official release tags a name prefix seems better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181213/c5534de4/attachment.html>

> On Dec 13, 2018, at 06:30, James Y Knight via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Thu, Dec 13, 2018 at 2:06 AM Justin Bogner <mail at justinbogner.com
<mailto:mail at justinbogner.com>> wrote:
> James Y Knight <jyknight at google.com <mailto:jyknight at
google.com>> writes:
> > 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).
I suggest, instead of "release/7.x", that we use
"release/7.0.x".  This aligns with how we only rev the 3rd part of the
tuple when tagging from this branch.

In the unexpected case that we have a bugfix that requires an ABI break after
7.0.0, we can create "release/7.1.x" for managing those tags.
> > - 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 <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.
> 
> 
> 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
> 
> Hm, that's a very good point. My preference would be
"llvm-8.0.0" now.
>  
> Branches are namespaced to their origin repository by default, so renaming
some in a downstream fork is no issue.
> 
> But tags are, by default, global. So if you did rename tags in a fork, and
someone pulled from both repositories, they get the union of all the tags
without being able to tell the source, or potentially even conflicts between
them. Giving the official release tags a name prefix seems better.
I have a mild preference for "llvm.org-8.0.0" (instead of
"llvm-8.0.0"), since llvm.org is unambiguously a point of origin,
whereas "llvm" could just refer to the content.  E.g., some
downstreams might package their product with the name "llvm".

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181213/38cef562/attachment.html>