On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane <g...@turnstep.com> wrote: > Mark wrote: >> Doesn't mean that packagers have to make new packages ... I personally >> think new packages shouldn't be made for anything older then *maybe* 3 >> releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit >> excessive ... but doing source tar balls is easy enough ... > > Andrew wrote: >> But the issue for me is not what vendors support but how often we ask >> someone to upgrade if they want to stay on a community supported base. >> As I remarked before, other things being equal, I think five years is a >> reasonable interval, and given that many users don't upgrade right on a >> .0 release, I think a release lifetime of about six years is therefore >> about right as a target. > > All of this ignores a huge reason why we have an implicit obligation to > support past releases for a long time: our horrible lack of an upgrade > option. That's only now starting to get remedied somewhat with pg_migrator, > Bucardo, and Slony, but the default way is still to do a dump-and-restore. > Until we can make this process take minutes instead of days for large > databases, > people are going to end up stuck to what version they are on. Knowing > they are going to have to do it all over again later is not going to > be very confidence inspiring. > > Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because > they necessarily want to, but they can't easily afford the downtime to > upgrade. Cutting them off arbitrarily early won't win us any friends. Once > pg_migrator (or better, in-place upgrades) is working well, we can start > setting > EOL on versions based on number of years of some other criteria.
At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 -> 8.4 upgrade. It isn't technically impossible for the 8.3 -> 8.5 path to be smoother than the current 8.3 -> 8.4 path, but nobody seems excited about working on it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers