Version management for extensions

Jeff Janes wrote:

I am facing a scenario where I have different version of an extension, say 1.0 and 2.0, which have
some different functionality between them (so not merely a bug fix), so people might want to continue
to use 1.0.

But changes to the PostgreSQL software between major versions requires changes to the extension's
source code.

So I basically have 4 versions to carry:

1.0_for_9.4_or_before
2.0_for_9.4_or_before
1.0_for_9.5
2.0_for_9.5

Is there some easy way to handle this? Are there examples of existing modules which have a similar
situation (and which handle it well) on PGXN or pgfoundry or other public repositories?

I don't think that there is an easy solution.

Could some #ifdefs make the same code work for 9.4 and 9.5?

Yours,
Laurenz Albe

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Fri, Oct 9, 2015 at 1:36 AM, Albe Laurenz <laurenz.albe@wien.gv.at>
wrote:

Jeff Janes wrote:

I am facing a scenario where I have different version of an extension,

say 1.0 and 2.0, which have

some different functionality between them (so not merely a bug fix), so

people might want to continue

to use 1.0.

But changes to the PostgreSQL software between major versions requires

changes to the extension's

source code.

So I basically have 4 versions to carry:

1.0_for_9.4_or_before
2.0_for_9.4_or_before
1.0_for_9.5
2.0_for_9.5

Is there some easy way to handle this? Are there examples of existing

modules which have a similar

situation (and which handle it well) on PGXN or pgfoundry or other

public repositories?

I don't think that there is an easy solution.

Could some #ifdefs make the same code work for 9.4 and 9.5?

Probably. But I probably shouldn't just pretend that the #ifdefs were
there all along for the already-released code. So if 1.0 was already in the
wild while 2.0 was not, you would still be left with something like:

1.0_for_9.4_or_before (perhaps make it uninstallable for new installations)
1.1_for_any_version_(so_far)
2.0_for_any_version_(so_far)

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).

Cheers,

Jeff

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general