Re: programmatic way to fetch latest release for a given major.minor version - Mailing list pgsql-general

From Dave Page
Subject Re: programmatic way to fetch latest release for a given major.minor version
Date
Msg-id 461B6F10.3040800@postgresql.org
Whole thread Raw
In response to Re: programmatic way to fetch latest release for a given major.minor version  (Magnus Hagander <magnus@hagander.net>)
Responses Re: programmatic way to fetch latest release for a given major.minor version  (Magnus Hagander <magnus@hagander.net>)
List pgsql-general
Magnus Hagander wrote:
> On Tue, Apr 10, 2007 at 09:52:52AM +0100, Dave Page wrote:
>> Magnus Hagander wrote:
>>> 2) Create a new file with a specific schema. Something like:
>>> <version>
>>>  <version major="8.2" minor="8.2.3" />
>>>  <version major="8.1" minor="8.1.8" />
>>> </version>
>>> This is the most lightweight solution.
>> More like:
>>
>> <versions>
>>   <version major="8" minor="2" revision="3" />
>>   <version major="8" minor="1" revision="8" />
>> </versions>
>
> But that doesn't reflect our terminology. Per our own terminology, bioth
> 8.1 and 8.2 are major versions. Not only is that what we've been saying for
> years, we even documented it at
> http://www.postgresql.org/support/versioning.

Yeah yeah, but terminology aside, having 2 or three digits in each
attribute is just wrong!

>> But I can't help thinking that we should have some additional values for
>> release notes, download sub-URLs (to be appended to the mirror roots) etc.
>
> Yeah, thus the X in XML :-)

:-p

> But given that we might want to add things like this, having our own custom
> XML format certainly makes a bit more sense, it might be harder to try to
> trick it into RSS.

Agreed.

/D

pgsql-general by date:

Previous
From: Listmail
Date:
Subject: Re: Bad plan using join on VALUES (and now on temp table too)
Next
From: Magnus Hagander
Date:
Subject: Re: programmatic way to fetch latest release for a given major.minor version