On Wed, Apr 28, 2021 at 3:29 PM Sehrope Sarkuni <sehrope@jackdb.com> wrote:
>
> On Tue, Apr 27, 2021 at 5:09 PM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>>
>> I would suggest modeling the query after what we are doing with the RSS
>> feed[2].
>
>
> Done. Updated patch is attached.
>
> It also renames some output fields ("tree" as "major" and "latestminor" as "minor") and adds a sort order on the JSON
fieldsto ensure stable output.
>
> $ curl -s http://localhost:8000/versions.json | jq last
> {
> "current": false,
> "eoldate": "2014-07-01",
> "major": "8.4",
> "minor": 0,
> "reldate": "2009-07-01",
> "supported": true
> }
I like the idea, btu a few comments:
* Why do we care about sorting the keys? Not that it matters much, but
it mostly seems a bit silly, but if there is a reasoning behind it
there's no problem -- I'd just like to know what the reasoning is.
* It reports major version as "13.0", not "13". It's correct for
versions prior to 10.
* In the XML/RSS feed we include a link to the release notes for the
version. Do we want to do that here as well? I'm thinking probably not
because (1) the RSS needs a clickable link, that's probably the only
reason it's there, and (2) release notes can now be found at
/docs/release/<version>/, which was not the case at the time of the
RSS feed being created. But I wanted to raise it for discussion in
case people would find it useful?
* I'm thinking the orignal name "latestminor" is actually better than
"minor" -- the previous minor releases still exist after all.
* Would it make sense to have an actual query parameter like
"?current=1" or something that would give you *just* the current
version? To avoid having to download all? And maybe also
"?supported=1" to get just supported versions? To avoid having to do
those filterings client side?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
