The other day I came across yet another company (who shall remain nameless, but are certainly not alone) who support using PostgreSQL as a backend for their product. And the support only version 8.2.3. While I prefer using 8.3 on all production servers today, I find it perfectly normal and acceptable that they don't support that, and only 8.2. What is not acceptable to me is only supporting 8.2.3. The 8.2 branch is currently at 8.2.11, and there are several critical bugs - including security issues - patched in these versions. I would not recommend any customer of mine to use 8.2.3 today.
So why is this? The only reason I can think of is that these company simply haven't bothered to figure out how the version numbering of the products actually works. For those who don't know, a quick intro to the PostgreSQL system: * Major versions are 8.0, 8.1, 8.2, 8.3 (no, you cannot reasonably claim to support "PostgreSQL version 8", which is also not uncommon, because that includes potentially incompatible future version) * Minor versions are 8.2.1, 8.2.2, 8.2.3 etc. * Minor versions contain only critical fixes. There are never new features introduced. There are almost never any kind of incompatible changes introduced (I say almost never, because it has happened when required to plug a security issue)
This should make it fairly obvious that it is counterproductive to support only 8.2.3. Because you are basically forcing the customers not to apply critical security fixes.
The fact that different databases follow different patterns here obviously makes it a little bit harder for the vendor. For example, it would not make sense to say you support MySQL 5.1. Because that can include both beta and release candidate versions. And they do regularly introduce new features and change behavior between versions like 5.1.x and 5.1.y. That's just how their numbering works. I don't personally like that way of numbering releases, but if I was putting out a product saying which versions of MySQL I support, I'd certainly read up on exactly how the version numbers work first.
If you cannot take the time to figure out how the release process of your database product works, why does it matter that you put in the version number at all? It's not likely it's properly supported anyway. That statement should be about "once tested with version x", not actually supported...
And to finish off: what I'd like to see is "we support version 8.2 starting at version 8.2.3" for example. That clearly identifies which major release is supported (8.2). And it also indicates that vendor takes it upon themselves to make sure their product continue working if the customer applies relevant security patches (AKA minor releases).
Ok, that's enough ranting for today...
no, this won't work. I have seen a software require a specific (outdated) patch level of AIX and DB2.
The way to fix it is to follow the same conventions that are used by ALL database vendors. Yes, I really mean all of them, except PostgreSQL. In the version number the first number indicates MAJOR RELEASE NUMBER. Period! The meaning of other parts of the version vendor, for example, virtually all vendors (MS is the main exception) use the second number to indicate minor release or maintenance version (new features, major bug fixes), the rest of the version (third and forth numbers) are used for builds, fix/patch levels, service packs, subversions, etc....
Um, that's just not so. MySQL uses the second number - 5.0 and 5.1 are both major. Microsoft don't even use version numbers anymore, they use the (approximate) year the product was released. Oracle uses a single number and a letter.
If PostgreSQL bumped the first number for each version we'd be at silly version numbers. Even worse than Oracle for example.
New comments can no longer be posted on this entry.
The way to solve this is no longer have minor releases. Instead have patch revs or "service packs" e.g;
We are at 8.2 service pack 11.
Its stupid but it would work.