-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
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.
- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200912021218
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAksWokQACgkQvJuQZxSWSsg5kACfdd9nZtHSG/KcOAIOGxVZ81/o
TUEAniaG4vWo4CY4v+3DlByJ4AZ6JXKP
=MyN9
-----END PGP SIGNATURE-----
