Re: Version management for extensions

On Fri, Oct 9, 2015 at 1:36 AM, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)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