On Fri, Oct 9, 2015 at 1:36 AM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> 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
