2 messages, 2 authors, 2016-06-15 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:59:43
"Philip Oakley" [off-list ref] writes:
Determining which is the current release note is possibly more problematic, which should be when making the documentation.
Hmmm.... Why? You are already aware of the stale-notes section, no? Isn't the top one the latest?
From: Philip Oakley <hidden>
Date: 2016-06-15 22:59:43
From: "Junio C Hamano" <redacted>
"Philip Oakley" [off-list ref] writes:quoted
Determining which is the current release note is possibly more problematic, which should be when making the documentation.Hmmm.... Why? You are already aware of the stale-notes section, no? Isn't the top one the latest?
It's that the 'git help release-notes' would _include_ the latest release notes, not just link to them (which is what the stalenotes currently does). Or at least that was the idea. Trying to determine the latest version, and then include those release notes, and the subsequent maint notes, into the putative "release-notes(7)" man page, without causing you any maintenance hassle, was the conceptual problem. I already have a local patch that creates a stalenote.txt file, and includes that in a "release-notes(7)" man page, but it still leaves the actual release notes in a separate plain text file, linked from the man page, rather than being right at hand, which is what I think readers would expect. My other question would be to ask how you normally manage the up-issue of the stalenotes, and when you would normally create that section in git(1) as I didn't see any ifdef::stalenotes[] being defined anywhere else. Philip