{"thread":{"id":"2915","subject":"[ANNOUNCE] GIT 1.0.3","startedAt":"2005-12-23T08:11:34Z","lastAt":"2005-12-23T08:11:34Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13976","messageId":"7voe389qrt.fsf@assigned-by-dhcp.cox.net","threadId":"2915","inReplyTo":null,"subject":"[ANNOUNCE] GIT 1.0.3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-23T08:11:34Z","receivedAt":"2005-12-23T08:11:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Only trivial fixes and cosmetics, there is nothing to see here,\nexcept the versioning scheme has been updated.\n\nStarting in 0.99.7 days and continuing until yesterday,\nmaintenance releases were named with letter suffixes, like\n0.99.7a, 0.99.7b,...  Some people seem to have had trouble with\ngrasping the concept [*1*] ;-)\n\nSo the numbering scheme switched to a boring decimal:\n\n - The maintenance releases that follow 1.0.0 are named 1.0.1,\n   1.0.2, 1.0.3,..., and contain only bugfixes [*2*].\n\n - The next release that follows 1.0.0 is 1.1.0, which, unlike\n   1.0.X, is allowed to have enhancements.\n\n - If one builds and installs from a random revision on the\n   \"master\" branch or \"pu\" branch after 1.0.0 happens but before\n   1.1.0 happens, \"git --version\" would say 1.0.GIT.  There will\n   not be such an intermediate state on the \"maint\" branch.\n\nI'll slow down until early next year and will not make a formal\nroadmap for 1.1.0 and onwards for now, but I've reviewed the\nTODO items and updated them here:\n\n    http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO\n\nI have not prioritized them quite yet, other than dropping a\ncouple of obviously unneeded or done items.\n\n\n[Footnote]\n\n*1* No, I did not model these release naming after military\njets, as somebody privately suggested me in an e-mail.  I had an\nimpression that letter updates over there are more often\nenhancements and/or repurposing to prolong the service life than\nbugfixes.  I mimicked ancient Linux versions with letter\nsuffixes, but come to think of it, they were more enhancements\nthan fixes, I suspect.\n\n*2* Inevitably there are borderline cases.  One could argue that\nthe [IPV6address] syntax is a fix: \"earlier we ought to have\nhandled it\".  The file:// URL failure case detection could be\ncalled enhancements: \"we never said we support file:// URL\".\n\n\nshortlog since 1.0.0b which should have been 1.0.2\n--------------------------------------------------\n\n\nAlex Riesen:\n      \\n usage in stderr output\n\nJohannes Schindelin:\n      git-format-patch should show the correct version\n      sha1_to_hex: properly terminate the SHA1\n\nJunio C Hamano:\n      send-pack: reword non-fast-forward error message.\n\nNick Hengeveld:\n      Fix for http-fetch from file:// URLs\n\nPavel Roskin:\n      sanity check in add_packed_git()\n"}]}