Обсуждение: Version management for extensions
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?
Cheers,
Jeff
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
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