Re: Extension Packaging

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Daniele Varrazzo <daniele(dot)varrazzo(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension Packaging
Date: 2011-04-25 12:49:01
Message-ID: BANLkTinKLC6SvoU_55KnTeY5hW71A5MG-w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 24, 2011 at 6:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)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 some more documentation
here.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-04-25 12:53:37 Re: make check in contrib
Previous Message Robert Haas 2011-04-25 12:45:53 Re: Unlogged tables, persistent kind