Hello, Neil Jerram <n...@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'.
