* Perry Wagle <wagle@xxxxxxxxxxxxxx> [080801 00:00]: > Jeff King has convinced me that it's perfectly legitimate to introduce > non-upward compatibilities in minor version releases of "young" > software. This is the gist of the problem. You keep hammering about a "non-upwards compatibilities in minor version releases", yet you have *not* pointed out one such in-compatibility in a minor version release.. Remember, in git, 1.6 is a "major version" release, with release notes, etc. 1.5.X is a "minor version" release. 1.5.X.Y is a "patch" release. It's a pretty normal versioning scheme. Git 1.5.X -> Git 1.6.X is a major release upgrade. And the Git 1.5 release notes have claimed for a while that git-<cmd> executibles are going to be moved out of the default path for a while. And the Git 1.6 release notes claimed they were... *And* git developpers have admitted that communication about that pending change was obviously insufficient... But that's a hard problem... How do developers make sure that users are reading release notes? *Especially* in a world where software is packaged up by systems/distros/etc. It's a problem that hits software across the board, linux kernel, PostgreSQL, glibc, gcc, X.org, HylaFAX, and yes, git. Git 1.5.4 has had the "git-exec-dir in path" deprecated for months. How can we do a better job of letting *users* know of the documented stuff in the release notes? Can you imagine the outcry if git was made to look for the config value core.hasreadreleasenotes.<version> on every invocation, and if it wasn't set, forced the releasenotes throught the pager? That way, you woudl have known 6 months ago that git had published release-notes saying that git-exec-dir change was going to happen... -- Aidan Van Dyk Create like a god, aidan@xxxxxxxxxxx command like a king, http://www.highrise.ca/ work like a slave.
Attachment:
signature.asc
Description: Digital signature
