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