# git version numbers 5 messages from 2011-05-28 to 2011-05-30. Participants: Tim Mazid, Jeff King, Jakub Narebski. Thread: https://gitlist.dev/t/27494 ## Tim Mazid, 2011-05-28 20:13 Subject: git version numbers Message-ID: <20110528201321.GA26017@Imperial-SD-Longsword> URL: https://gitlist.dev/e/20110528201321.GA26017%40Imperial-SD-Longsword ``` Hi list, I was just looking at various versioning schemes, and I came to wonder about git's one. Most of the ones out there are of the form .. (j.n.r), but git seems to have four, as in 1.7.5.1. So, I was wondering what you call each number in the git version; does the usual j.n.r apply to the last three and the first one is a "mystery"? What is the official versioning scheme? Does each number have any particular name? Tim. () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ``` ## Jeff King, 2011-05-30 03:34 Subject: Re: git version numbers Message-ID: <20110530033428.GB27691@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110530033428.GB27691%40sigill.intra.peff.net In-Reply-To: <20110528201321.GA26017@Imperial-SD-Longsword> ``` On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote: > I was just looking at various versioning schemes, and I came to wonder > about git's one. Most of the ones out there are of the form > .. (j.n.r), but git seems to have four, > as in 1.7.5.1. > > So, I was wondering what you call each number in the git version; does > the usual j.n.r apply to the last three and the first one is a > "mystery"? What is the official versioning scheme? Does each number > have any particular name? In "git w.x.y.z", the decoding is: w: not likely to change short of a complete rewrite or something that is quite incompatible (i.e., will probably remain "1" for quite a while) x: when this jumps, it is a "big" version change, meaning there may be some minor incompatibilities or new ways of doing things. For example, 1.5.0 introduced a lot of usability changes and the separate-remotes layout became the default. In 1.6.0, we stopped shipping "git-*" in the PATH, and started using some new packfile features by default. And so on. If you want to know more, see Documentation/RelNotes/1.?.0.txt. y: when this jumps, it is a new release cut from master that does not have any "big" changes as above. There will be new features and some bugfixes. See RelNotes/1.7.?.txt for examples of what gets included. z: when this jumps, it is a bugfix release based on the feature release w.x.y. See RelNotes/1.7.5.?.txt for examples. Getting more to your actual question, I don't know that we ever use any particular name like "major" or "minor" for any of them. We do tend to use the terms "feature release" for w.x.y releases and "bugfix release" for w.x.y.z. -Peff ``` ## Tim Mazid, 2011-05-30 06:06 Subject: Re: git version numbers Message-ID: <20110530060653.GB3723@Imperial-SD-Longsword> URL: https://gitlist.dev/e/20110530060653.GB3723%40Imperial-SD-Longsword In-Reply-To: <20110530033428.GB27691@sigill.intra.peff.net> ``` On Sun, May 29, 2011 at 11:34:28PM -0400, Jeff King wrote: > In "git w.x.y.z", the decoding is: > > w: not likely to change short of a complete rewrite or something that > is quite incompatible (i.e., will probably remain "1" for quite a > while) > > x: when this jumps, it is a "big" version change, meaning there may be > some minor incompatibilities or new ways of doing things. For > example, 1.5.0 introduced a lot of usability changes and the > separate-remotes layout became the default. In 1.6.0, we stopped > shipping "git-*" in the PATH, and started using some new packfile > features by default. And so on. If you want to know more, see > Documentation/RelNotes/1.?.0.txt. > > y: when this jumps, it is a new release cut from master that does not > have any "big" changes as above. There will be new features and > some bugfixes. See RelNotes/1.7.?.txt for examples of what gets > included. > > z: when this jumps, it is a bugfix release based on the feature > release w.x.y. See RelNotes/1.7.5.?.txt for examples. > > Getting more to your actual question, I don't know that we ever use any > particular name like "major" or "minor" for any of them. We do tend to > use the terms "feature release" for w.x.y releases and "bugfix release" > for w.x.y.z. Ah; I see. The system I was considering was essentially identical, except instead of calling it w.x.y.z, they are actually named them in the form of ..-. As for the decoding, it's identical: super-major is an almost never change number; major is when there's something "big"; minor is when there's a "release", but it's not "big"; and revision for a bugfix. Well, thanks for the clarification. While we're on the topic, though, when I was scouring the web for information, I found a post [1] which spoke against the traditional numbering versioning system. Personally, I disagree and find the "dating" version cumbersome and uninformative. So, I was wondering what your [2] take on this is. Tim. [1] http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html [2] By "you", I mean anybody in the list, of course. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ``` ## Jeff King, 2011-05-30 14:25 Subject: Re: git version numbers Message-ID: <20110530142544.GB31490@sigill.intra.peff.net> URL: https://gitlist.dev/e/20110530142544.GB31490%40sigill.intra.peff.net In-Reply-To: <20110530060653.GB3723@Imperial-SD-Longsword> ``` On Mon, May 30, 2011 at 04:06:55PM +1000, Tim Mazid wrote: > While we're on the topic, though, when I was scouring the web for > information, I found a post [1] which spoke against the traditional > numbering versioning system. Personally, I disagree and find the > "dating" version cumbersome and uninformative. So, I was wondering what > your [2] take on this is. I agree with you. I am sympathetic to the position that giant version numbers can be confusing to end users, but I hope it is clear from my previous email that each of those numbers has a meaning, and that developers, system administrators, and clueful users can see from the version number what they should expect to change. A simpler versioning scheme loses that information. -Peff ``` ## Jakub Narebski, 2011-05-30 14:40 Subject: Re: git version numbers Message-ID: URL: https://gitlist.dev/e/m3ipssxnf4.fsf%40localhost.localdomain In-Reply-To: <20110530033428.GB27691@sigill.intra.peff.net> ``` Jeff King writes: > On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote: > > > I was just looking at various versioning schemes, and I came to wonder > > about git's one. Most of the ones out there are of the form > > .. (j.n.r), but git seems to have four, > > as in 1.7.5.1. > > > > So, I was wondering what you call each number in the git version; does > > the usual j.n.r apply to the last three and the first one is a > > "mystery"? What is the official versioning scheme? Does each number > > have any particular name? > > In "git w.x.y.z", the decoding is: > > w: not likely to change short of a complete rewrite or something that > is quite incompatible (i.e., will probably remain "1" for quite a > while) > > x: when this jumps, it is a "big" version change, meaning there may be > some minor incompatibilities or new ways of doing things. For > example, 1.5.0 introduced a lot of usability changes and the > separate-remotes layout became the default. In 1.6.0, we stopped > shipping "git-*" in the PATH, and started using some new packfile > features by default. And so on. If you want to know more, see > Documentation/RelNotes/1.?.0.txt. > > y: when this jumps, it is a new release cut from master that does not > have any "big" changes as above. There will be new features and > some bugfixes. See RelNotes/1.7.?.txt for examples of what gets > included. > > z: when this jumps, it is a bugfix release based on the feature > release w.x.y. See RelNotes/1.7.5.?.txt for examples. > > Getting more to your actual question, I don't know that we ever use any > particular name like "major" or "minor" for any of them. We do tend to > use the terms "feature release" for w.x.y releases and "bugfix release" > for w.x.y.z. I think that Git numbering scheme actually follows semver pattern used by Linux kernel... which just moved to scheme: x.y[.z] from w.x.y[.z] one https://lkml.org/lkml/2011/5/29/204 == http://lwn.net/Articles/445222/ http://lwn.net/Articles/445223/ Though git still breaks backward compatibility from time to time (separate remotes by default, not shipping git-xxx n PATH, deltabaseoffset, submodules, packed refs, push safeties, status != commit --dry-run) which change 'x'... though probably could change 'w' (thought we be then at 7.x with git codebase still in flux...). -- Jakub Narebski Poland ShadeHawk on #git ```