On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> This gives my first problem. I can't package afoo-2.x seperately from >> afoo-1.x, because they both want to write the afoo control file. > > No, you ship *one* package that supports both 1.1 and 2.0. Hm... As an example of a project that generally has pretty good software release practices, I'm glat that the PostgreSQL project doesn't operate this way. Having to download/install/upgrade a package with all of pg 9.1.$lateset and 9.0.$latest just to get a fix for 8.4.$latest would be a bit of a bummer... And a hopefull extension author/packages/user, I *want* to be able to release/distribute different versions seperately, just like PostgreSQL does. And I'll do that by packaging my extension with a "major" version in the name, much like the packages for PostgreSQL does. But once I've done that, I don't need the multiple extension versions, all I need is the ability to run $something when I upgrade an extension, once the files under it have been upgraded. ;-) >> But now, let's make it harder. I've found a grave bug in 1.1, which >> causes the PG backend to segfault. Easy fix, good thing, so now I >> release 1.2: > > 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. Right. If everything is exactly binary compatible and it's just a .so fix, I don't need to. But let's assume something like slonly (or bucardo or longdiste, or PyQ, or PostGIS) start's trying to make use of extensions. I can very much see a "bug fix" minor version upgrade changing things that might need trigers/etc to be altered to take advantage of the fixed way of doing things. Or a SQL view/function had a bug with an null handling joins that needs fixing, etc. Lots of reasons for an "upgrade" to need to change an SQL object. And of course, if I have slony 1.2.$x replicating one of my databases, I'ld love to be able to try slony 2 and have it packaged on my system too to test somethign else. And not have to upgrade my slony 2 instance just to get the critical bugfix for my production slony 1.2$x+1. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
