From: Tim Mazid <hidden> Date: 2016-06-15 22:51:20
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
From: Jeff King <hidden> Date: 2016-06-15 22:51:20
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
From: Tim Mazid <hidden> Date: 2016-06-15 22:51:20
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
From: Jeff King <hidden> Date: 2016-06-15 22:51:21
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
From: Jakub Narebski <hidden> Date: 2016-06-15 22:51:21
Jeff King [off-list ref] writes:
On Sun, May 29, 2011 at 06:13:22AM +1000, Tim Mazid wrote:
quoted
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