* Perry Wagle [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- 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. 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@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.