(original) (raw)
On Thu, Dec 13, 2018, 4:49 AM Hans Wennborg <hans@chromium.org wrote:
On Thu, Dec 13, 2018 at 5:54 AM James Y Knight via llvm-dev
<llvm-dev@lists.llvm.org> wrote:
\>
\> On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman@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.