|| ||Junio C Hamano <email@example.com>|
|| ||firstname.lastname@example.org, email@example.com|
|| ||[ANNOUNCE] GIT 1.0.3|
|| ||Fri, 23 Dec 2005 00:11:34 -0800|
Only trivial fixes and cosmetics, there is nothing to see here,
except the versioning scheme has been updated.
Starting in 0.99.7 days and continuing until yesterday,
maintenance releases were named with letter suffixes, like
0.99.7a, 0.99.7b,... Some people seem to have had trouble with
grasping the concept [*1*] ;-)
So the numbering scheme switched to a boring decimal:
- The maintenance releases that follow 1.0.0 are named 1.0.1,
1.0.2, 1.0.3,..., and contain only bugfixes [*2*].
- The next release that follows 1.0.0 is 1.1.0, which, unlike
1.0.X, is allowed to have enhancements.
- If one builds and installs from a random revision on the
"master" branch or "pu" branch after 1.0.0 happens but before
1.1.0 happens, "git --version" would say 1.0.GIT. There will
not be such an intermediate state on the "maint" branch.
I'll slow down until early next year and will not make a formal
roadmap for 1.1.0 and onwards for now, but I've reviewed the
TODO items and updated them here:
I have not prioritized them quite yet, other than dropping a
couple of obviously unneeded or done items.
*1* No, I did not model these release naming after military
jets, as somebody privately suggested me in an e-mail. I had an
impression that letter updates over there are more often
enhancements and/or repurposing to prolong the service life than
bugfixes. I mimicked ancient Linux versions with letter
suffixes, but come to think of it, they were more enhancements
than fixes, I suspect.
*2* Inevitably there are borderline cases. One could argue that
the [IPV6address] syntax is a fix: "earlier we ought to have
handled it". The file:// URL failure case detection could be
called enhancements: "we never said we support file:// URL".
shortlog since 1.0.0b which should have been 1.0.2
\n usage in stderr output
git-format-patch should show the correct version
sha1_to_hex: properly terminate the SHA1
Junio C Hamano:
send-pack: reword non-fast-forward error message.
Fix for http-fetch from file:// URLs
sanity check in add_packed_git()
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/