[m-dev.] Renaming the NEWS file -> NEWS.md

Zoltan Somogyi zoltan.somogyi at runbox.com
Wed Feb 21 00:10:15 AEDT 2018

On Tue, 20 Feb 2018 08:01:04 -0500 (EST), Julien Fischer <jfischer at opturion.com> wrote:
> > - The list of changes to library modules should have *exactly one*
> >  entry for any library module it mentions. Having more than one
> >  entry can be confusing for readers.
> So, something like
>    # Changes to the Mercury standard library
>    ## Changes to the array module
>        .
>        .
>        .
>    ## Changes to the char module
>        .
>        .
>        .
> etc etc?

> > - Those entries should be sorted by module name. This should help us
> >   enforce the "only one mention" rule, and allows readers to find
> >   what they are interested in using binary search.
> >
> > - Likewise, changes to compiler options should be described in
> >   exactly one entry (the usual change being the addition of the option),
> >   and the entries should be sorted by option name.
> > We should also consider having the NEWS.md file for a full release
> > include the changes since the previous full release, as now, but
> > moving those changes to the HISTORY file (HISTORY.md?)
> One thing at a time

If you moved the part of the NEWS file dealing with the last full release
to the HISTORY file, you will have to convert less text to the markdown

> (and if you think the NEWS file is a bit
> of a mess you *really* don't want to look at the HISTORY file).

That was a throwaway comment. We are not the Ministry of Truth;
we should leave HISTORY unchanged.

> > immediately afterwards, so that between full releases (i.e. the vast
> > majority of the time), NEWS.md contains only the changes that
> > happened *since* the last full release.
> >
> > We should probably delete the TODO file. We have not used it
> > in years (possibly decades :-( ).
> You're working on one of the things in that file right now!

May be, but I didn't start working on it *because* of the TODO file.

> Mind you, the contents of that file do seem to be a mixture of the
> out-of-date, the trivial, the vague and absolutely gigantic pieces of
> work.

Exactly. For project outsiders, who cannot be expected to be able
to tell those categories apart, this makes it a less-than-useful guide
to what we may be working on.


More information about the developers mailing list