Re: Release note trimming: another modest proposal

[Jonathan S. Katz]

On 8/30/18 4:15 PM, Magnus Hagander wrote:
> On Fri, Aug 10, 2018 at 1:38 AM, Peter Eisentraut
>  > wrote:
> 
> On 06/08/2018 00:57, Tom Lane wrote:
> > Anyway, I'd like to propose a compromise position that I don't think
> > has been discussed before: let's drop release notes for branches
> > that were already EOL when a given branch was released.  So for
> > example, 9.3 and before would go away from v12, due out next year.
> > Working backwards, we'd drop 9.1 and before from v10, giving the 15%
> > savings in page count that I showed above.  A quick measurement says
> > that would also trim the size of the v10 tarball by about 4%, which
> > is not a lot maybe but it's noticeable across a lot of downloads.
> 
> Why not go further and just ship the release notes of the current major
> version.  If you want to look at the release notes of version 11, read
> the documentation for version 11.  Who reads the documentation of
> version 12 to get the release notes of version 11?
> 
> 
> +1 for that. At least if we get a generic release notes index up on the
> website, easy to find.

So circling back on this, Peter's point makes a lot of sense.

If you want to see release notes for other major versions, there would
be URLs to the other major versions, but that would be far less costly
than keeping the actual release notes in each tarball.

So for example, let's take PostgreSQL 11:

https://www.postgresql.org/docs/11/release.html

We could do something like:

==snip==
- Release 11.1
Migration to Version 11.1
Changes
- Release 11.0
Migration to Version 11.1
Changes

Older Major Versions:

PostgreSQL 10 [URL to https://www.postgresql.org/docs/10/release.html]
PostgreSQL 9.6 [URL to https://www.postgresql.org/docs/9.6/release.html]
etc. etc.
== snip ==

That would both save significant space and hopefully solve the archiving
problem, as we would have the older docs available with all of their
respective versions.

The downside would be the PDFs, you would not have all the release notes
for, say PostgreSQL 10, in the PostgreSQL 11 PDFs. But I would argue
does that really matter? I could see that being helpful if you're
migrating between versions, but if you're using PostgreSQL 11, you're
using PostgreSQL 11 and the information for that version is the most
relevant.

It also seems like it'd make it easier to maintain the release notes
too, which would be another big win in addition to the build speedup.

Thoughts?

Jonathan



signature.asc
Description: OpenPGP digital signature

Re: First SVG graphic

[Jürgen Purtz]

My questions to the community are:

  * Does anyone has an idea how to generate single HTML file in the
actual situation?



Thanks to an additional template created by Alexander Lakhin, which 
extends the 'nochunk' stylesheet for SVG and MathML processing, it is 
now possible to create the "single HTML file" of our documentation 
including SVG. For me this is a working solution as long as we use 
Docbook 4. After the migration to Docbook 5, both languages as well as 
full namespace support will be natively included in Docbook.


Does anyone faced some more problems? Or can we start to include the 
three first SVG graphics into PG's documentation?


Kind regards

Jürgen Purtz



diff --git a/doc/src/sgml/stylesheet-html-nochunk.xsl b/doc/src/sgml/stylesheet-html-nochunk.xsl
index ffd2012e91..3a20a47bce 100644
--- a/doc/src/sgml/stylesheet-html-nochunk.xsl
+++ b/doc/src/sgml/stylesheet-html-nochunk.xsl
@@ -9,4 +9,23 @@
 
 
 
+
+  
+
+  
+
+  
+
+  
+
+http://www.w3.org/1998/Math/MathML; test="mml:*">
+  
+
+http://www.w3.org/2000/svg; test="svg:*">
+  
+
+  
+  
+
+