Re: Extension Packaging - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Extension Packaging
Date
Msg-id BANLkTinKLC6SvoU_55KnTeY5hW71A5MG-w@mail.gmail.com
Whole thread Raw
In response to Re: Extension Packaging  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extension Packaging  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
On Sun, Apr 24, 2011 at 6:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <david@kineticode.com> writes:
>> On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
>>> Hmm ... it's sufficient, but I think people are going to be confused as
>>> to proper usage if you call two different things the "version".  In RPM
>>> terminology there's a clear difference between "version" and "release";
>>> maybe some similar wording should be adopted here?  Or use "major
>>> version" versus "minor version"?
>
>> I could "distribution version" =~ s/version/release/; Frankly, the way the terminology is now it's halfway-there
already.
>
>> So distribution semver release 1.1.0 might contain extension semver version 1.0.0.
>
>> Hrm, Still rather confusing.
>
> Yeah.  It seems like a bad idea if the distribution "name" doesn't
> include sufficient information to tell which version it contains.
> I had in mind a convention like "distribution version x.y.z always
> contains extension version x.y".  Seems like minor version versus
> major version would be the way to explain that.

I think it's a bit awkward that we have to do it this way, though.
The installed version of the extension at the SQL level won't match
what the user thinks they've installed.  Granted, it'll be in the
ballpark (1.0 vs 1.0.3, for example) but that's not quite the same
thing.  I also note that we've moved PDQ from thinking that versions
are opaque strings to having pretty specific ideas about how they are
going to have to be assigned and managed to avoid maintainer insanity.That suggests to me that at a minimum we need
somemore documentation 
here.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Unlogged tables, persistent kind
Next
From: Robert Haas
Date:
Subject: Re: make check in contrib