From: Jakub Narebski <jnareb@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Tim Mazid <timmazid@hotmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: git version numbers
Date: Mon, 30 May 2011 07:40:44 -0700 (PDT) [thread overview]
Message-ID: <m3ipssxnf4.fsf@localhost.localdomain> (raw)
In-Reply-To: <20110530033428.GB27691@sigill.intra.peff.net>
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
prev parent reply other threads:[~2011-05-30 14:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-28 20:13 git version numbers Tim Mazid
2011-05-30 3:34 ` Jeff King
2011-05-30 6:06 ` Tim Mazid
2011-05-30 14:25 ` Jeff King
2011-05-30 14:40 ` Jakub Narebski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3ipssxnf4.fsf@localhost.localdomain \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=timmazid@hotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.