[llvm-dev] New LLVM git repository conversion prototype

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 19 11:25:25 PST 2018


On Wed, Dec 19, 2018 at 1:21 AM Hans Wennborg via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Dec 19, 2018 at 1:12 AM Tom Stellard via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > 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?
>
> Maybe llvm.org-8.0.0-final for the final one, similar to what we do
> currently? Otherwise sgtm.
>
> > 2. Tags for commits in the master branch that bump the release version.
>
> I may have missed something in the thread, but do we actually *need* this?
>

That enables `git describe` to return the right version name while in
master (and indicates the number of commits since the branching point)

See David's email here:
http://lists.llvm.org/pipermail/llvm-dev/2018-November/127822.html

-- 
Mehdi


>
> > 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?
>
> I think it's important that a tag actually describes what the commit
> is. "v8.0.0-dev" or "-git" sounds like it's the development version of
> 8.0.0, which it's not -- as proposed, it's really the first commit
> after 7.0.0 was branched.
>
> If we really need a tag for this, and I'm not sure we do, I think we
> should instead tag the commit that we branch from, i.e.
> v7.0.0-branchpoint. If brevity is important, it could be just "v7-bp".
>
> I propose that we don't block on having these.
>
>
> > 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?
>
> That sgtm.
>
> Thanks,
> Hans
>
>
>
>
> > > 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
> > >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181219/317a5095/attachment.html>


More information about the llvm-dev mailing list