Hans Wennborg via llvm-dev
2018-Dec-13 15:06 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at google.com> wrote:> > On Thu, Dec 13, 2018, 4:49 AM Hans Wennborg <hans at chromium.org wrote: >> >> 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? > > > We don't *need* it, no. But it might be useful. > > The purpose of this tag would not be for people to check out, but rather to allow "git describe" to return more interesting results when run on master. > > See David Jones' email from Nov 16.Ah, okay. "git describe" is new to me :-) I still think v8.0.0-base is a better name though. v8.0.0-dev really sounds like something one might check out to get the latest dev version.
Alex Bradbury via llvm-dev
2018-Dec-13 15:18 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Thu, 13 Dec 2018 at 15:07, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at google.com> wrote:> > We don't *need* it, no. But it might be useful. > > > > The purpose of this tag would not be for people to check out, but rather to allow "git describe" to return more interesting results when run on master. > > > > See David Jones' email from Nov 16. > > Ah, okay. "git describe" is new to me :-) I still think v8.0.0-base is > a better name though. v8.0.0-dev really sounds like something one > might check out to get the latest dev version.v8.0.0-branchpoint might be even clearer, though obviously a little longer. Best, Alex
David Jones via llvm-dev
2018-Dec-13 16:31 UTC
[llvm-dev] New LLVM git repository conversion prototype
On Thu, Dec 13, 2018 at 7:18 AM Alex Bradbury via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Thu, 13 Dec 2018 at 15:07, Hans Wennborg via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Dec 13, 2018 at 3:34 PM James Y Knight <jyknight at google.com> > wrote: > > > > We don't *need* it, no. But it might be useful. > > > > > > The purpose of this tag would not be for people to check out, but > rather to allow "git describe" to return more interesting results when run > on master. > > > > > > See David Jones' email from Nov 16. > > > > Ah, okay. "git describe" is new to me :-) I still think v8.0.0-base is > > a better name though. v8.0.0-dev really sounds like something one > > might check out to get the latest dev version. > >Hmm, I wouldn't worry too much about checking out an old tag by accident... that puts your client into detached head state, and git prints a nice, long warning. (That sort of mistake should be obvious pretty quickly.) v8.0.0-branchpoint might be even clearer, though obviously a little longer.>Whatever the convention we choose, it's going to be painful to change once folks get used to it. (So the wording of the tag is not entirely inconsequential.) My expectation is that the `git describe` aliases will be the typical way to refer to commits in a git world, and aliases like v8.0.0-branchpoint-1234-abcdef seem a bit long to me... when I think about how often I type "rNNNNNN" today, the "-branchpoint" part seems almost obsequious. For a development tag, we should probably try to keep it short, simple, and obvious. After all, we're fundamentally talking about a tag used for development, not releases; something short, like "master-v8" would yield concise, obvious aliases like "master-v8-1234-abcdef01". (Tags on release branches are a fundamentally different matter, and could continue looking exactly like they do today.) FWIW, the conventions I've seen have been inconsistent. One possible consideration: the "-dev" suffix is sometimes used to indicate a dirty workspace, but git describe puts the --dirty suffix after the hash. (So it's unambiguous, in any case.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181213/790fc7dc/attachment.html>