From: Junio C Hamano <gitster@pobox.com>
To: "Philip Oakley" <philipoakley@iee.org>
Cc: "GitList" <git@vger.kernel.org>,
"Stefan Nwe" <stefan.naewe@atlas-elektronik.com>
Subject: Re: [PATCH] Git release notes man page
Date: Wed, 19 Feb 2014 10:22:09 -0800 [thread overview]
Message-ID: <xmqqha7v9d4e.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1EC26D492ABB45FF8C399F84B1E30817@PhilipOakley> (Philip Oakley's message of "Tue, 18 Feb 2014 22:54:15 -0000")
"Philip Oakley" <philipoakley@iee.org> writes:
>> RelNotes are incremental and only useful for those who know what the
>> immediately previous release contained, but for most people who get
>> their Git from distros, I have this impression that the versions of
>> Git they get skip versions, and seeing the notable changes since the
>> previous source release will not give them wrong information---they
>> may have this warm fuzzy feeling that they know what is going on,
>> but they are missing information on all the accumulated changes that
>> were added in earlier versions their distro skipped---these changes
>> are still in the version they are running.
>
> That's a reasonable argument.
I am not making an "argument" in order to reject the notion of
making release-notes available, though. I am only raising concerns,
pointing out why showing a single release notes as if that were the
only one that matter is misleading.
I am not opposed to the idea of making release notes available to
those who do not install from the source, by the way. Being able to
grep the release notes through may help people who are writing
scripts using Git to learn when a feature they want to use appeared
to make sure that they do not depend on something their users may
not have yet. But for that kind of users, it would be more helpful
to point them at the file location they can find the plain text
version of release notes, instead of giving them a bunch of web
links they need to read through page by page.
> I did look at trying to get the
> "stalenotes" to work as an alternative, that is extract the stalenotes
> section from the git.txt, and create a release notes man page from
> that.
I am not sure if stale-notes section meshes well with this; the
primary purpose of it was to point at the whole documentation set,
not just release-notes, for versions previously released, so those
who came to a website that hosts them can pick the version, possibly
a stale one, that they are using and read the manual pages for that
version, without seeing newer features that are not available to
them. I do not think it is very useful in the context of your "You
received this single version of software, and you can access its
documentation off-line" feature---you cannot reasonably expect that
such a software release to contain all the past documentation sets,
but even if you could do so, that is not how normal people use the
installed documentation, i.e. to learn about older releases that
they no longer have.
next prev parent reply other threads:[~2014-02-19 18:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 10:29 [PATCH] Git release notes man page Philip Oakley
2014-02-15 10:29 ` [PATCH] [PATCH] Provide a release-notes man page / guide Philip Oakley
2014-02-18 22:14 ` [PATCH] Git release notes man page Junio C Hamano
2014-02-18 22:54 ` Philip Oakley
2014-02-19 9:06 ` Stefan Näwe
2014-02-19 18:22 ` Junio C Hamano [this message]
2014-02-18 23:05 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqha7v9d4e.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
--cc=stefan.naewe@atlas-elektronik.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.