Justin Bogner via llvm-dev
2018-Nov-17 03:10 UTC
[llvm-dev] 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.
James Y Knight via llvm-dev
2018-Dec-13 04:53 UTC
[llvm-dev] New LLVM git repository conversion prototype
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>
Justin Bogner via llvm-dev
2018-Dec-13 07:06 UTC
[llvm-dev] 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.
Hans Wennborg via llvm-dev
2018-Dec-13 09:49 UTC
[llvm-dev] New LLVM git repository conversion prototype
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?
Tom Stellard via llvm-dev
2018-Dec-19 00:12 UTC
[llvm-dev] New LLVM git repository conversion prototype
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 >