Splitting up release.sgml

(I'm sure this has come up before, but it hasn't got done for some
reason...)

I think it's time for $SUBJECT.  release.sgml is growing at a rate
of several thousand lines per major release and several hundred for
each group of minor releases.  It's getting to be a pain to edit,
and I don't even want to think about how large the underlying RCS
file must be.  This clearly doesn't scale for the long term.

What I propose we do is:

Create a separate file for each major release branch, eg
release-8.3.sgml for the 8.3.x series.  This will contain exactly
the <sect1> ... </sect1> material that is currently in release.sgml
for that branch.

It's probably not worth carrying out the above split back beyond 8.0.
I suggest throwing 7.4 and all prior branches into one file
release-old.sgml.

This will leave release.sgml containing just the chapter header
material and include directives for the release-xxx.sgml files.
In the future it will change only to add a new include line
when a new major branch is started.

I propose making this change in the active back branches, not only HEAD.
This will mean that the process for updating back-branch release notes
reduces to copying the appropriate release-xxx.sgml files into each
older branch; we won't need the major_release_split script, which is
rather dangerous because it doesn't understand that the header material
has to be different in the oldest branches.  (In this scheme, the link
difference is still located in the release.sgml file, but that doesn't
change anymore in back branches so there's no risk of overwriting it.)

Thoughts?

            regards, tom lane