Josh Berkus <j...@agliodbs.com> writes:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01
> 8.0 2010-02-01
> 8.1 2011-01-01
> 8.2 2012-01-01
> 8.3 2013-03-01
> 8.4 2014-08-01
I have no objection to setting an EOL date for 7.4 now, but I think it
is premature to set EOL dates for later versions. I suppose the policy
you have in mind here (but are not spelling out) is that versions will
be EOL'd five years after release no matter what. I'm not convinced
that we need to have a policy for that at all; but if we were to set
one, I'd prefer to define it in terms of the maximum number of back
branches we want to deal with. (So it'd go more like "a version will be
EOL'd shortly after the release of the fifth subsequent major version".)
Or, if you want something calendar-based, it should be driven off the
release of the immediately following major version (i.e., "not less than
four years after the release of the next major version"), so that people
would always know that they have at least N years' support when they
adopt the current major version.
But on the whole I think we should NOT have such a policy, at all.
If we'd enunciated such a thing in 2005, we'd still be on the hook to
support 8.0 on Windows; or else have had to go back on our word. The
truth of the matter is that the community will make reasonable efforts
to support back branches but we are not going to set anything in stone.
If someone wants a guaranteed EOL date, they ought to be contracting
with a commercial support company and paying appropriately.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
