Re: Release Notes Archive Patch

Hi,

On 2/19/19 5:42 AM, Magnus Hagander wrote:

> A few comments on this one:
>
> 1. It loses the "go to next minor" and "go to previous minor" links in
> the previous release notes. Those should be easy enough to get back, but
> should be done. E.g. if I'm on 9.6.3, I want links to 9.6.2 and 9.6.4.
> And we should also use the change to make it more "explicit" and *also*
> have a link to 9.6.0 on all of them amonst the links themsel
>
> 2b. In fact, we should use this chance to create a proper set of links,
> e.g. when you get to release notes for 9.6.0, it should right then and
> there provide a list of all the minor releases I think -- to avoid
> having to go back.

So there could be an issue with that as we would have to carry the
lag/lead somehow. Not insurmountable, but given this is minimally
invasive, it would take a bit more complicating of that SQL query that
was just simplified.

>
> 2. Links within the docs are just plain broken? E.g. the 9.6.0 release
> notes link to /docs/release/9.6.0/app-pg-dumpall.html which clearly
> doesn't exist. IIRC we discussed something around this, but it seems to
> have never made it into the patches? (It is listed in your known
> adjustments to be made above, but I could also not find a newer patch?)

I could not reproduce this. The links work fine for me.

>
> 3. That SQL query really needs some documentation, because it takes
> quite a bit of reading to figure out what it really means. And while it
> works on my dev install, it fails when i test-ran it on the current
> database with the error "ERROR:  invalid input syntax for type numeric:
> "prior". Most likely it comes from there being a file called
> release-prior.html in versions 9.4-11.0 now. 
>
> It should also be reviewed for the fact that you are pulling back *all*
> the documentation including *all* the contents in order to render a list
> of versions...That gets annoyingly expensive when you actually have the
> full set of documentation.

Per off-list discussion, Magnus added a simpler query that was provided.

>
> 4. The "jump to..." list should probably be split between supported and
> unsupported versions, to keep it a bit less.

Well, with the below, I don't think we need that.

>
> 5. In general, there's a huge amount of numbers on the index page. I'm
> not sure what's a good way to format it better, I normally leave that to
> you :) But the page is not very friendly at this point with the massive
> list of numbers you have to scroll through.

We could list out the major versions, then have the minor versions. I'm
not opposed to that. See attached.


Jonathan