On Tue, Feb 13, 2007 at 09:44:22AM -0800, Junio C Hamano wrote:
quoted text
> As the text assumes familiarity with git 1.3.0 or so, I am not
> sure if making it as one of the manpages makes much sense.

Yeah, that's a good point.

quoted text
> Also there is a question of what to do when 1.6.0 comes out.
> Will its release notes replace 1.5.0 one?  If so changes from
> which version will it describe?

What I've seen some projects do (including some commercial products)
is to keep them around with the old file names.  So if we have

Documentation/RELEASE-NOTES_1.5.0.txt
Documentation/RELEASE-NOTES_1.6.0.txt
Documentation/RELEASE-NOTES_1.7.0.txt

and a symlink from RELEASE-NOTES to Documentation/RELEASE-NOTES-<cur_ver>.txt

that would make a lot of sense....

quoted text
> and have pointer to v1.5.0.txt from Documentation/git.txt would
> be a sensible and easy thing to do.

The only reason why I suggest Documentation/RELEASE-NOTES_1.5.0.txt
instead of Documentation/v1.5.0.txt is that it might not be as obvious
what "v1.5.0.txt" is for someone just looking at it in the
Documntation directory, where as "RELEASE-NOTES_1.5.0.txt leaves no
doubt.

But keeping the the old release notes around is good both for people
who are upgrading from older versions, and it also means that for
someone who wants to answer the question, "suppose we want to enable
feature <foo>", what which older versions of git clients will be
breaking.  

(I was about to suggest that we just break the older git clients using
dumb http protecols on kernel.org, befure I realized that that meant
breaking git clients that were released last August.  Whoops; it's
amazing how much improvements git has seen in the last six months,
that it seems a lot longer ago... :-)

							- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html