Re: complex number reader bug?

Re: complex number reader bug?

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Below is a patch for review.  It was an interesting problem, as I
> haven't gone very far into Guile's number handling code before.

I've pushed this to master too, and that raises two points about the
organization of master's NEWS.

Firstly, now that 1.9.0 has been released, I'm not sure it makes sense
for 1.9.x NEWS to refer to `Changes in 1.8.x' for x >= 7.  It seems
more natural for NEWS to refer to actual releases in chronological
order, so I think the right thing would be for

- `Changes in 1.9.0 (changes since the 1.8.x series)' to be renamed
  `Changes in 1.9.0 (changes since 1.8.6)'

- all of the `Changes in 1.8.7 (since 1.8.6)' items to be merged into
  `Changes in 1.9.0 (changes since 1.8.6)'.

Secondly, are we going to retain the distinctions between the 1.9.x
releases, once 2.0 is released?  I would guess yes, because I see no
point in discarding information that might be useful.

If so, note that it's worth taking care to get the right place when
adding a missing NEWS item for something that was already in a
previous release - which I think is a good thing to do, so that the
1.8.x - 2.0 NEWS is as complete as possible.  I.e. if we now find
something that should have been in the NEWS for 1.9.0, we
retrospectively insert it into the `Changes in 1.9.0 (changes since
1.8.6)' section, and not into `Changes in 1.9.1 (changes since
1.9.0)'.

Does that all sound right?

(If it does, I will need to move the NEWS for this complex number fix
to `Changes in 1.9.1 (changes since 1.9.0)'.)

Regards,
        Neil

Re: complex number reader bug?

[Ludovic Courtès]

Hello,

Neil Jerram <neil@ossau.uklinux.net> writes:

> Firstly, now that 1.9.0 has been released, I'm not sure it makes sense
> for 1.9.x NEWS to refer to `Changes in 1.8.x' for x >= 7.

IMO, when 2.0 is released, we really want to show changes since the
1.8.x series, i.e., essentially broad changes, rather than changes
compared to a specific 1.8 release.

Normally, all bug fixes that apply both to 1.8 and `master' will be
indeed applied to both branches.  Thus, bug fixes like this one should
not appear under "Changes between 2.0 and 1.8.x".

> Secondly, are we going to retain the distinctions between the 1.9.x
> releases, once 2.0 is released?  I would guess yes, because I see no
> point in discarding information that might be useful.

IIRC Andy suggested that the current 1.9.0 entries would evolve until
2.0 is actually out.  IOW, the NEWS that will come with 2.0+ would not
even mention the 1.9 releases.

I think it's the right approach, given that 1.9.x releases are
development releases.  OTOH, it also makes sense to record changes
between 1.9.n and 1.9.(n + 1) so that testers have an idea of what has
happened recently.  Concretely, that would mean maintaining two NEWS
file though (say, NEWS and NEWS-1.9), which is slightly annoying.

Regrettably, the GNU Standards don't say anything about how to manage
the NEWS file in the presence of parallel stable/unstable branches (info
"(standards) NEWS Files").

Thanks,
Ludo'.