Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

* Perry Wagle <wagle@cs.indiana.edu> [080801 00:00]:

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...