Messages in this thread | | | From | Junio C Hamano <> | Subject | [ANNOUNCE] GIT 1.3.1 | Date | Tue, 25 Apr 2006 01:04:55 -0700 |
| |
The latest maintenance release GIT 1.3.1 is available at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.3.1.tar.{gz,bz2} (tarball) RPMS/$arch/git-*-1.3.1-1.$arch.rpm (RPM)
Just to let people who are new to the game know, 1.3.X (1<=X) series is purely bugfix maintenance on top of 1.3.0 release, and no new features will be added unless there is a compelling reason (think of them like 2.6.16.X releases of the kernel, slightly looser updates criteria).
There are four primary branches in git.git repository.
* Releases in the 1.3.X series come from the "maint" branch, which was forked at 1.3.0.
* All the new features and improvements start their life as topic branches that are merged to the "pu" (proposed updates) branch. They are often incomplete and/or unstable. You can think of "pu" as the -mm.
* When these topic branches become stable enough, they are merged into "next" branch. I personally run "next" branch for my work to trust my data to it, until very close to the next feature release.
* After being cooked for a few days to a week in "next", these good changes graduate to the "master" branch. Some of them die while being cooked there, but that does not happen very often (bad apples are culled while in "pu").
I make feature release out of "master" branch periodically, which are tagged as X.Y.0 releases. At that point, "maint" branch is forked to prepare X.Y.1 and onward.
If you are an end user, the "maint" releases are the recommended stale releases, but you could miss out new features quickly. Please do send in bug reports for them, but do not expect new cool features to appear there.
If you want to stay current and stable, I would recommend to track "master".
If you are a git developer, being aware of what is happening in "next" would often be very helpful. The infrastructure you plan to base your change on may be in the process of being updated and your changes to "master" can become useless when that happens.
If you are a truly devoted git hacker, picking what is in "pu" can be exciting and useful from time to time.
Post 1.3.0 "master" branch development currently contains major rewrite of log/show/whatchanged infrastructure, and will be getting updated pack-objects, faster write-tree, consolidated "git diff" that is not a shell script, and hopefully many others. To reiterate, they will be part of 1.4.0 and no 1.3.X series release will have them.
----------------------------------------------------------------
Changes since v1.3.0 are as follows:
Jonas Fonseca: Fix filename scaling for binary files
Junio C Hamano: git-merge: a bit more readable user guidance. pre-commit hook: complain about conflict markers. git-commit --amend: two fixes. pack-objects: do not stop at object that is "too small" mailinfo: decode underscore used in "Q" encoding properly.
Linus Torvalds: git-log produces no output
Nicolas Pitre: fix pack-object buffer size
Paul Mackerras: rev-parse: better error message for ambiguous arguments
Petr Baudis: Document git-var -l listing also configuration variables Document the configuration file
Santi Béjar: Reintroduce svn pools to solve the memory leak.
Serge E. Hallyn: socksetup: don't return on set_reuse_addr() error
Shawn Pearce: Document git-clone --reference
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |