Debian PostgreSQL Versioning

Stewart over at Flaming Spork [http://www.flamingspork.com/blog/2006/04/19/beat-on-state-of-the-dolphin-or-why-software-is-never-really-ready-until-a-20-release/ posits the theory] that software at version X.X.0 can be expected to not work, that by X.X.10 it get’s pretty good, and by X.X.20 it is actually something you can use without worry. He names a number of projects that follow this model, the linux kernel, gnome, and mysql. Unfortunatly he get’s tripped up looking at PostgreSQL, partially because we don’t tend to need that many bugfix releases, and partially because he is running debian, which tells him he is on 7.5.9. Well, here’s my attempt at clarification: Around the time of 7.4/8.0, Debian renumbered their postgresql version numbers to reflect distribution specific changes that they made to the package; mostly a number of changes to allow better support of multiple major postgresql versions via thier packaging system. In the postgresql core code there was never a 7.5 release (the 7.5 development branch got changed to 8.0), hence the confusion. If you are running 7.5.x, you’re really running 7.4.x era code, and (IMHO) you ought to [http://www.debian-administration.org/articles/373 upgrade] to something a bit newer (8.1.3 is a good one) To address the broader idea, I think if you want to apply this metric to postgresql, you need a factor of 10 multiplier… ie 8.1.0 was an ok release in test, by 8.1.1 it started to get really usable, and by 8.1.2 it was solid for pretty much everyone. I’m not exactly sure why it is so different; Probably becuase the PostgreSQL development team is pretty thorough about not introducing new features in bugfix releases, and also partly because they allow non-critical bugfixes to accumlate before putting out releases; but that’s been my general experience with PostgreSQL versions.