Re: Splitting up release.sgml

Поиск
Список
Период
Сортировка
От Guillaume Lelarge
Тема Re: Splitting up release.sgml
Дата
Msg-id 200904260908.16053.guillaume@lelarge.info
обсуждение исходный текст
Ответ на Splitting up release.sgml  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-docs
Le samedi 25 avril 2009 à 21:28:46, Tom Lane a écrit :
> [...]
> 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.
>

I completely agree. This huge file is also really painful for translators.
Splitting it will make the job easier.

> 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.
>

I would have included 7.4 branch in this, but that's not really a big issue.

> 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.)
>

I'm also OK with this.


--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com

В списке pgsql-docs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Splitting up release.sgml
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: XML documentation question