git version numbers

git version numbers

[Tim Mazid]

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

Re: git version numbers

[Jeff King]

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.

-Peff

Re: git version numbers

[Tim Mazid]

[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]

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 <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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: git version numbers

[Jeff King]

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

Re: git version numbers

[Jakub Narebski]

Jeff King <peff@peff.net> 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
> > <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