threads / discuss / 27494

git version numbers

Subject: git version numbers

## tl;dr

5 messages between May 28, 2011 and May 30, 2011.

replies: 4people: 3as markdown or json

Tim Mazid· May 28, 2011, 20:13 UTC · lore

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 <major>.<minor>.<optional revision> (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· May 30, 2011, 03:34 UTC · re: Tim Mazid · lore

Re: git version numbers

On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote:

Show 9 quoted lines

> 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
> <major>.<minor>.<optional revision> (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· May 30, 2011, 06:06 UTC · re: Jeff King · lore

Re: git version numbers

On Sun, May 29, 2011 at 11:34:28PM -0400, Jeff King wrote:

Show 26 quoted lines

> 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 <super-major>.<major>.<minor>-<optional revision>. 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· May 30, 2011, 14:25 UTC · re: Tim Mazid · lore

Re: git version numbers

On Mon, May 30, 2011 at 04:06:55PM +1000, Tim Mazid wrote:

Show 5 quoted lines

> 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· May 30, 2011, 14:40 UTC · re: Jeff King · lore

Re: git version numbers

Jeff King <peff@peff.net> writes:

Show 38 quoted lines

> 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
> > <major>.<minor>.<optional revision> (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