Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- Date: Fri, 29 Aug 2008 11:24:51 -0400
- From: Aidan Van Dyk <aidan@xxxxxxxxxxx>
- Subject: Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
* 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
- Follow-Ups:
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Felipe Contreras
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- References:
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Linus Torvalds
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Teemu Likonen
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Jeff King
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Jeff King
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- From: Perry Wagle
- Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- Prev by Date: Re: How to create a branch without any links to the others branches
- Next by Date: Re: [PATCH v4] Expand ~ and ~user in core.excludesfile, commit.template
- Previous by thread: Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- Next by thread: Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins
- Index(es):