public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: [email protected]
Subject: Splitting up release.sgml
Date: Sat, 25 Apr 2009 15:28:46 -0400
Message-ID: <[email protected]> (raw)

(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

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Splitting up release.sgml
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox