Bill Moran wrote:
I spend some time googling this and searching the Postgresql.org site, but
I'm either not good enough with the search strings, or it's not to be found.
I'm trying to plan upgrades so that we don't upgrade needlessly, but also
don't get caught using stuff that nobody's supporting any more.
The FreeBSD project keeps this schedule:
http://www.freebsd.org/security/#adv
which is _really_ nice when talking to managers and similar people about
when upgrades need to be scheduled.
Does the PostgreSQL project have any similar policy about EoLs? Even just
a simple statement like, "it is our goal to support major branches for 2
years after release" or some such?
There is no set time frame planned that I know of.
It is more a matter of users that keep the old versions alive. Some with
large datasets on busy servers that can't allocate enough downtime to
upgrade tend to be keeping the older versions running.
As far as I know there are some companies that support the security
fixes being back-ported to 7.x releases and this is the only reason they
do get updates and are still listed on the site. There is some developer
desire to drop 7.x altogether.
v8.0 has been available for 2 years now and a common first answer to
support questions for anything older is to upgrade.
If they are running PostgreSQL on Windows then they should be using 8.1
at least and be encouraged to stay more up to date as the Windows
version is still young and less tested and is getting more improvements
with each release.
I would not suggest that you have any clients use less than 8.0 with 8.1
preferred and 8.2 for new installs.
But as the old saying goes if it ain't broke don't fix it. If the
version they have runs fine and fulfills their need then leave it be.
Upgrading at the same time as hardware can be a good way to go if you
aren't interested in always having the newest version.
--
Shane Ambler
pgSQL@xxxxxxxxxxxxxxxx
Get Sheeky @ http://Sheeky.Biz
