Re: Version management for extensions

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Version management for extensions
Date: 2015-10-19 09:32:38
Message-ID: 5624B8B6.6040703@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 10/18/15 6:43 PM, Jeff Janes wrote:
>
> It seems like there should be some way to mark a feature-release of an
> extension, versus a server-compatibility-only release (also versus a
> bug-fix-in-extension release).

The problem is worse than that: the 'version' string for an extension is
just that: a dumb string. So you can't even do intelligent >
comparisons, unless you're really careful with how you define your
string. If we had semantic versions you could at least mark bug releases
without blowing things up.

I don't see any great way to handle comparability other than to have
different extension names. I don't really see it as a problem though...
normally when something adds compatability with a new environment it's
done as part of a version release.

What might be interesting would be allowing the control file to specify
what PG versions are supported.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jim Nasby 2015-10-19 09:39:55 Re: ERROR: tablespace "archive2" is not empty
Previous Message Jim Nasby 2015-10-19 09:25:39 Re: ID column naming convention