On Mon, 26 Sep 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Maybe something like this would do: "We will attempt to maintain support
of each major version for 3 years after its release, although this will
not always be possible. After that time any major support requirement is
likely to result in support being ended."
This sounds reasonable to me ... I think it is more then most software
projects do, isn't it?
To translate that into reality: 7.2 (2002-02-04) would be dead already,
and 7.3 (2002-11-27) will be dead around the time we are likely to
release 8.1. Do people feel comfortable with that? It seems to fit
with what I'd like to do right at the moment, which is to release
updates back to 7.3 but not 7.2.
IMHO ... after 3 years of running on a version, if someone hasn't hit some
of the bugs that we're back-patching for, the either aren't going to, or
should have that as an encouragement to upgrade ... in most cases, I
believe that alot of the ones you've back patched for, its something
you've fixed in a "recent release", and ended up going looking for in past
releases to make sure they were safe ... no?
I'd prefer to measure the time from the release of the follow-on
version, so I'd make it "2 years from release of following major
version"; that would give people a clearer idea of the time frame
in which they're expected to update their applications. But I'm not
wedded to that.
'k, if you mean 'major version' == x.0 (ie. 7.0.0, 8.0.0), then I think
the span of time + 2 years is *way* too long, considering an average of,
what, 5 years between major releases ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
