Peter Eisentraut <peter_e@gmx.net> writes:
> On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
>> Unless the bug is such that you have to change the installation script
>> file, there is no reason to bump the version number at all. These
>> version numbers apply to the install SQL script, not the
>> underlying .so.
> I think this shows that the installation script version number should be
> independent of the overall package's version number. You just change
> the installation script version number when it is required that the
> script be run as part of an upgrade, otherwise you leave it. This is
> very similar to the version numbers of shared libraries, which also
> change independently of the overall package.
> So perhaps installation script version numbers should just be integers
> starting at 1, period.
Well, people are certainly free to use them that way, but I'm not sure
there's much to be gained by forcing it. What I'd sort of assumed we
would do with the contrib scripts is major.minor, where a bump in the
minor number is for a compatible upgrade (ie, run ALTER EXTENSION UPDATE
and you're good) while a bump in the major number would be for
incompatible changes.
> Otherwise I fear people will try to make the numbers match their package
> version number, which will either create stupid installation script
> sequences or stupid package version numbers, like those peculiar fellows
> who change the shared library version number in accordance with their
> package version number.
I hear you, but even if we did restrict script versions to integers,
people would still be tempted to sync them with some part of their
package version number, and then they'd still get burnt. I think this
is more a matter for documentation of how-you-should-use-this than
something we can try to force programmatically.
> This would of course also simplify many other aspects about which
> version numbers to allow and how to compare them.
It would enable comparisons, but we don't seem to need those after all.
I don't think it really solves any problems in filename parsing, unless
you'd like to disallow digits in extension names ...
regards, tom lane