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

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