{"thread":{"id":"27494","subject":"git version numbers","startedAt":"2011-05-28T20:13:22Z","lastAt":"2011-05-30T14:40:44Z","messageCount":5,"participants":["Tim Mazid","Jeff King","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168925","messageId":"20110528201321.GA26017@Imperial-SD-Longsword","threadId":"27494","inReplyTo":null,"subject":"git version numbers","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-28T20:13:22Z","receivedAt":"2011-05-28T20:13:22Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"Hi list,\n\nI was just looking at various versioning schemes, and I came to wonder\nabout git's one.  Most of the ones out there are of the form\n<major>.<minor>.<optional revision> (j.n.r), but git seems to have four,\nas in 1.7.5.1.\n\nSo, I was wondering what you call each number in the git version; does\nthe usual j.n.r apply to the last three and the first one is a\n\"mystery\"?  What is the official versioning scheme?  Does each number\nhave any particular name?\n\n\nTim.\n\n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org   - against proprietary attachments\n"},{"id":"168965","messageId":"20110530033428.GB27691@sigill.intra.peff.net","threadId":"27494","inReplyTo":"20110528201321.GA26017@Imperial-SD-Longsword","subject":"Re: git version numbers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-30T03:34:28Z","receivedAt":"2011-05-30T03:34:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote:\n\n> I was just looking at various versioning schemes, and I came to wonder\n> about git's one.  Most of the ones out there are of the form\n> <major>.<minor>.<optional revision> (j.n.r), but git seems to have four,\n> as in 1.7.5.1.\n> \n> So, I was wondering what you call each number in the git version; does\n> the usual j.n.r apply to the last three and the first one is a\n> \"mystery\"?  What is the official versioning scheme?  Does each number\n> have any particular name?\n\nIn \"git w.x.y.z\", the decoding is:\n\n  w: not likely to change short of a complete rewrite or something that\n     is quite incompatible (i.e., will probably remain \"1\" for quite a\n     while)\n\n  x: when this jumps, it is a \"big\" version change, meaning there may be\n     some minor incompatibilities or new ways of doing things. For\n     example, 1.5.0 introduced a lot of usability changes and the\n     separate-remotes layout became the default. In 1.6.0, we stopped\n     shipping \"git-*\" in the PATH, and started using some new packfile\n     features by default. And so on. If you want to know more, see\n     Documentation/RelNotes/1.?.0.txt.\n\n  y: when this jumps, it is a new release cut from master that does not\n     have any \"big\" changes as above. There will be new features and\n     some bugfixes. See RelNotes/1.7.?.txt for examples of what gets\n     included.\n\n  z: when this jumps, it is a bugfix release based on the feature\n     release w.x.y. See RelNotes/1.7.5.?.txt for examples.\n\nGetting more to your actual question, I don't know that we ever use any\nparticular name like \"major\" or \"minor\" for any of them. We do tend to\nuse the terms \"feature release\" for w.x.y releases and \"bugfix release\"\nfor w.x.y.z.\n\n-Peff\n"},{"id":"168972","messageId":"20110530060653.GB3723@Imperial-SD-Longsword","threadId":"27494","inReplyTo":"20110530033428.GB27691@sigill.intra.peff.net","subject":"Re: git version numbers","fromName":"Tim Mazid","fromEmail":"timmazid@hotmail.com","sentAt":"2011-05-30T06:06:55Z","receivedAt":"2011-05-30T06:06:55Z","isPatch":false,"sender":{"key":"timmazid@hotmail.com","avatar":null},"body":"On Sun, May 29, 2011 at 11:34:28PM -0400, Jeff King wrote:\n> In \"git w.x.y.z\", the decoding is:\n> \n>   w: not likely to change short of a complete rewrite or something that\n>      is quite incompatible (i.e., will probably remain \"1\" for quite a\n>      while)\n> \n>   x: when this jumps, it is a \"big\" version change, meaning there may be\n>      some minor incompatibilities or new ways of doing things. For\n>      example, 1.5.0 introduced a lot of usability changes and the\n>      separate-remotes layout became the default. In 1.6.0, we stopped\n>      shipping \"git-*\" in the PATH, and started using some new packfile\n>      features by default. And so on. If you want to know more, see\n>      Documentation/RelNotes/1.?.0.txt.\n> \n>   y: when this jumps, it is a new release cut from master that does not\n>      have any \"big\" changes as above. There will be new features and\n>      some bugfixes. See RelNotes/1.7.?.txt for examples of what gets\n>      included.\n> \n>   z: when this jumps, it is a bugfix release based on the feature\n>      release w.x.y. See RelNotes/1.7.5.?.txt for examples.\n> \n> Getting more to your actual question, I don't know that we ever use any\n> particular name like \"major\" or \"minor\" for any of them. We do tend to\n> use the terms \"feature release\" for w.x.y releases and \"bugfix release\"\n> for w.x.y.z.\n\nAh; I see.  The system I was considering was essentially identical,\nexcept instead of calling it w.x.y.z, they are actually named them in\nthe form of <super-major>.<major>.<minor>-<optional revision>.  As for\nthe decoding, it's identical: super-major is an almost never change\nnumber; major is when there's something \"big\"; minor is when there's a\n\"release\", but it's not \"big\"; and revision for a bugfix.\n\nWell, thanks for the clarification.\n\nWhile we're on the topic, though, when I was scouring the web for\ninformation, I found a post [1] which spoke against the traditional\nnumbering versioning system.  Personally, I disagree and find the\n\"dating\" version cumbersome and uninformative.  So, I was wondering what\nyour [2] take on this is.\n\n\nTim.\n\n[1] http://www.codinghorror.com/blog/2007/02/whats-in-a-version-number-anyway.html\n[2] By \"you\", I mean anybody in the list, of course.\n\n-- \n() ascii ribbon campaign - against html e-mail\n/\\ www.asciiribbon.org   - against proprietary attachments\n"},{"id":"168996","messageId":"20110530142544.GB31490@sigill.intra.peff.net","threadId":"27494","inReplyTo":"20110530060653.GB3723@Imperial-SD-Longsword","subject":"Re: git version numbers","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-30T14:25:44Z","receivedAt":"2011-05-30T14:25:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 30, 2011 at 04:06:55PM +1000, Tim Mazid wrote:\n\n> While we're on the topic, though, when I was scouring the web for\n> information, I found a post [1] which spoke against the traditional\n> numbering versioning system.  Personally, I disagree and find the\n> \"dating\" version cumbersome and uninformative.  So, I was wondering what\n> your [2] take on this is.\n\nI agree with you. I am sympathetic to the position that giant version\nnumbers can be confusing to end users, but I hope it is clear from my\nprevious email that each of those numbers has a meaning, and that\ndevelopers, system administrators, and clueful users can see from the\nversion number what they should expect to change. A simpler versioning\nscheme loses that information.\n\n-Peff\n"},{"id":"168998","messageId":"m3ipssxnf4.fsf@localhost.localdomain","threadId":"27494","inReplyTo":"20110530033428.GB27691@sigill.intra.peff.net","subject":"Re: git version numbers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-30T14:40:44Z","receivedAt":"2011-05-30T14:40:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote:\n> \n> > I was just looking at various versioning schemes, and I came to wonder\n> > about git's one.  Most of the ones out there are of the form\n> > <major>.<minor>.<optional revision> (j.n.r), but git seems to have four,\n> > as in 1.7.5.1.\n> > \n> > So, I was wondering what you call each number in the git version; does\n> > the usual j.n.r apply to the last three and the first one is a\n> > \"mystery\"?  What is the official versioning scheme?  Does each number\n> > have any particular name?\n> \n> In \"git w.x.y.z\", the decoding is:\n> \n>   w: not likely to change short of a complete rewrite or something that\n>      is quite incompatible (i.e., will probably remain \"1\" for quite a\n>      while)\n> \n>   x: when this jumps, it is a \"big\" version change, meaning there may be\n>      some minor incompatibilities or new ways of doing things. For\n>      example, 1.5.0 introduced a lot of usability changes and the\n>      separate-remotes layout became the default. In 1.6.0, we stopped\n>      shipping \"git-*\" in the PATH, and started using some new packfile\n>      features by default. And so on. If you want to know more, see\n>      Documentation/RelNotes/1.?.0.txt.\n> \n>   y: when this jumps, it is a new release cut from master that does not\n>      have any \"big\" changes as above. There will be new features and\n>      some bugfixes. See RelNotes/1.7.?.txt for examples of what gets\n>      included.\n> \n>   z: when this jumps, it is a bugfix release based on the feature\n>      release w.x.y. See RelNotes/1.7.5.?.txt for examples.\n> \n> Getting more to your actual question, I don't know that we ever use any\n> particular name like \"major\" or \"minor\" for any of them. We do tend to\n> use the terms \"feature release\" for w.x.y releases and \"bugfix release\"\n> for w.x.y.z.\n\nI think that Git numbering scheme actually follows semver pattern used\nby Linux kernel... which just moved to  scheme: x.y[.z] from w.x.y[.z]\none\n\n  https://lkml.org/lkml/2011/5/29/204 == http://lwn.net/Articles/445222/\n  http://lwn.net/Articles/445223/  \n\nThough git still breaks backward compatibility from time to time\n(separate remotes by default, not shipping git-xxx n PATH,\ndeltabaseoffset, submodules, packed refs, push safeties, status !=\ncommit --dry-run) which change 'x'... though probably could change 'w'\n(thought we be then at 7.x with git codebase still in flux...).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}