On Mon, Sep 26, 2005 at 09:07:45PM -0700, Joshua D. Drake wrote:
A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main
On Mon, Sep 26, 2005 at 08:54:49PM -0700, Josh Berkus wrote:
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that.
Tom Lane wrote:
To my mind the main rationale for continuing to support 7.2 is that it
was the last pre-schema release, and so people whose apps haven't yet
been fixed to cope with schemas will be on their own once we drop it.
While each release has some portability gotchas, I don't think there
On Mon, Sep 26, 2005 at 09:54:46PM -0700, Joshua D. Drake wrote:
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no* way anyone could provide you anything that
has any legitimate claim on the name PG 8.2 three months from now.
I **think** what he
[EMAIL PROTECTED] (Steve Atkins) writes:
We started our upgrade from 7.2 to 7.4 about 20 months ago and finished it
about 10 months ago, skipping 7.3 entirely.
We did similar; there was only one system deployed in a timeframe
where 7.3 was relevant, and the big systems skipped over 7.3 much as
Steve,
The only crystal ball involved is the assumption that if bizgres has
Neat Stuff(tm) that would be of widespread use in it's development
tree at that point then the odds are good that it, or something
functionally equivalent to it, will appear in the 8.2 development
tree.
It certainly
On Mon, 26 Sep 2005, Josh Berkus wrote:
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that
[EMAIL PROTECTED] (Marc G. Fournier) writes:
On Mon, 26 Sep 2005, Josh Berkus wrote:
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited
Hi,
On Mon, 26 Sep 2005, Tom Lane wrote:
snipped
This brings up the question of whether we should officially abandon
support for 7.2 and/or later branches. I don't think anyone is planning
on supporting old branches forever, but when do we stop?
I have a corporate need to keep supporting
Devrim GUNDUZ [EMAIL PROTECTED] writes:
There are some 7.3 users around (I remember some on Slony lists, etc),
therefore we should keep supporting it. But maybe we can announce that
7.3 will become unsupported after XXX time so that people will know
before we abandon the support. The best
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like X amount of time after the release of the
following major version. But X probably has to depend on how big
the compatibility gotchas are in the following version, so we're still
On Mon, 26 Sep 2005, Andrew Dunstan wrote:
Tom Lane wrote:
If we want to have some sort of fixed policy for support lifespan, I
would suggest it be like X amount of time after the release of the
following major version. But X probably has to depend on how big
the compatibility gotchas are
[ Forgot to answer this part ]
Devrim GUNDUZ [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
I have a corporate need to keep supporting 7.3, at least to the extent
of critical bug fixes, because Red Hat is still on the hook to support
that version in RHEL3 for awhile longer.
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
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
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.
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 26 Sep 2005, Tom Lane wrote:
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
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
Joshua D. Drake [EMAIL PROTECTED] writes:
I think there should be levels of support.
There already are, in that only fairly major bugs get backpatched to the
way-back releases. I think that's right --- the older a release is, the
more it means that people still using it value stability over the
On Mon, Sep 26, 2005 at 05:57:08PM -0400, Tom Lane wrote:
I had originally been planning to back-port this fix:
http://archives.postgresql.org/pgsql-committers/2005-08/msg00213.php
as far as 7.2. I've completed the back-port as far as 7.3, but
found that 7.2 would be significantly more work
The question at hand is when are we willing to pull the plug
completely and declare that even security holes and data-loss risks
won't get fixed.
It is definitely a sensitive issue because we (my community hat on) want
to make sure
and not alienate people because we won't support a version
Tom,
Or, as you say, we could take the viewpoint that there are commercial
companies willing to take on the burden of supporting back releases, and
the development community ought not spend its limited resources on doing
that. I'm hesitant to push that idea very hard myself, because it would
On Mon, Sep 26, 2005 at 09:27:28PM -0400, Andrew Dunstan wrote:
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
A nice pg_upgrade utility would make a big difference. Clearly an
in-place upgrade is possible, but maintaining is hard. There are two
broad ways of running a pg_upgrade project - one that is entirely
independent of the main codebase and one that puts requirements on the
main codebase
Steve Atkins [EMAIL PROTECTED] writes:
We'll be skipping 8.0 completely and the next step will probably be to
8.1.something (or possibly 8.2.something, depending on how bizgres
looks in 3 months time).
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no*
[ raised eyebrow... ] Has bizgres obtained a crystal ball from
somewhere? There is *no* way anyone could provide you anything that
has any legitimate claim on the name PG 8.2 three months from now.
I **think** what he meant was that depending on what Bizgres has done in
the next three
26 matches
Mail list logo
