gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-devel] [task #13897] Revision history for the manual


From: Mohammad Akhlaghi
Subject: [gnuastro-devel] [task #13897] Revision history for the manual
Date: Sun, 01 May 2016 06:56:10 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0

Follow-up Comment #2, task #13897 (project gnuastro):

Now that I read the initial post again, I see that it contains too many
"should"s and apparently doesn't allow any flexibility! This task was not
intended to be an order (to my self or others), it was meant to be a
suggestion and open to discussion so we can implement it later after some
thought. So sorry for the bad tone.

The file keeping the variable information is indeed not tracked in my initial
idea. The basic implementation I had in mind was something like how we use
doc/findversion.sh. In that script, the version numbers are read from the
main.h file in all the utilities to generate an output (which is read by
Texinfo). We keep a history of (or track) doc/findversion.sh, but we don't
keep a history of its output (since it isn't a hand-written file).

The manual is often created after all the commits have been done and none of
the manual output formats are version controlled. Let's assume the script is
called genrevhistory.sh. We can add the output of this script as a dependency
for gnuastro.texi in doc/Makefile.am (just like findversions.sh). So as you
mentioned, adding the hash, or date or any other name/number can be easily
done without tracking it.

I agree that the hash is not very useful within the documentation, and the
important thing is the date. The main thing I was thinking about was to help
an interested person find the associated commit easily. But now that I think
more about it, I agree with your point: it just adds to complexity (for a
reader who doesn't know what a hash or version control is). If someone is
interested in the commit, the date and commit title/details are enough to
allow them to find the commit easily. So we can ignore the hash as you
suggested. Thank you.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?13897>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]