On 9/1/19 7:24 pm, Sebastian Huber wrote: > The usage of a build date prevents reproducible builds.
Sorry to revisit this change. I have reviewed the generated the docs and they look good and the changes are welcome, thank you. I would like to ask a few questions. 1. Can the hash be the short version? I am seeing in the PDF in the page header: Release 5.0.0.05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603 (9th January 2019) which is correct but the page header is now 2 lines and a line on a page in the PDF is precious. In the Classic API manual at 716 pages this is 716 extra lines. Can we use a shortened hash? 2. Should: 5.0.0.05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603 be: 5.0.0-05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603 ? This separates the version number from the hash and helps avoid confusion. For example it took me a while to figure out if the version was 5.0.0.0 and the hash 5d066a08fe840f6f926bf6d2f3f3c0ebd6cc603. It would also be consistent with the other places the hash is used, for example the rtems-tools programs. 3. Can the git commit date (9th January 2019) please be added to the footer line in the HTML version? This makes the information available the PDF and HTML equivalent. Thanks Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
