<div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 17 Dec 2025 at 13:00, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com">zoltan.somogyi@runbox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Tue, 16 Dec 2025 23:37:04 +1100, Julien Fischer <<a href="mailto:jfischer@opturion.com" target="_blank">jfischer@opturion.com</a>> wrote:<br>
> On Tue, 16 Dec 2025 at 18:06, Zoltan Somogyi <<a href="mailto:zoltan.somogyi@runbox.com" target="_blank">zoltan.somogyi@runbox.com</a>><br>
> wrote:<br>
> <br>
> > For review by anyone. The diff does not include the automatically-updated<br>
> > getopt.m.<br>
> ><br>
> > I would like feedback on<br>
> ><br>
> > - whether we should change the argument order of record_arguments<br>
> > to match the new record_all_arguments (I think we should, since it was<br>
> > added after the last release), and<br>
> ><br>
> <br>
> Yes.<br>
<br>
Except that I was basing "it was added after the last release" on the mistaken<br>
belief that the entry for that library module that I modified was from after<br>
the last release. I now know that it was from *before* the last release.<br>
Is your answer still yes?<br></blockquote><div><br></div><div>Yes.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - whether we should use the new functionality to let mmc continue<br>
> > doing its job in the presence of bad options.<br>
> ><br>
> <br>
> What do you mean by "continue doing its job"? Presumably, we still<br>
> stop at some point and complain about the bad options?<br>
<br>
I mean doing the same job as if the bad option was not there, *except*<br>
for printing a diagnostic about that bad option.<br></blockquote><div><br></div><div>That's potentially a problem if some of those bad options were meant to</div><div>be setting up things that the rest of compilation requires to be error free.</div><div>(I'm thinking particularly of options that control the target language</div><div>compilation environment here.)<br></div><div>Your diagnostic about the bad option may get swamped by other error</div><div>messages.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> (Perhaps we should move the 22.01 news into the HISTORY file now, rather<br>
> than waiting until just before the creation of the next release branch?)<br>
<br>
It would definitely eliminate the chance of mistakes like this. I also do not see<br>
what benefit we get from having the news for the last release in that file.<br></blockquote><div><br></div><div>At the time we release a stable version, there is a small benefit to</div><div>having the news for the latest release in the NEWS file because it is easily</div><div>found. (At that point, however, there is unlikely to be any post-release news.)<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think the main obstacle of moving that section to the HISTORY file is that<br>
HISTORY contains plain text, and not markdown. </blockquote><div><br></div><div>The HISTORY file already contains a mixture of markdown, sort-of-markdown</div><div>and non-markdown. At the end of the day, markdown *is* plain text, so I don't</div><div>see it as that much of a problem.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would guess that everyone<br>
would agree with the propositions that<br>
<br>
- there is no point in converting the existing contents of HISTORY to use markdown, and<br></blockquote><div><br></div><div>I wouldn't say there's no point, it's just a really low priority item.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- we do not want to mix plain text and markdown text in the same file.<br></blockquote><div><br></div><div>Too late!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I therefore propose that we move te 22.01.* news to a new HISTORY.md file,<br>
with a note at the end saying that the history continues in the plain HISTORY file.<br>
Or maybe we could name the two files HISTORY_SINCE_2022.md and<br>
HISTORY_BEFORE_2022.<br></blockquote><div><br></div><div>I am fine with just adding the old entries to the HISTORY file. There's already too</div><div>many documentation-type files floating about at the top-level of the source tree.</div><div> </div><div>Julien.<br></div></div></div>