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
> >
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
[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
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
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 w
[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
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
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
h
[ 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
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
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 developers
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 maj
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
lo
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
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 wor
"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
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 seem
"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 wh
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
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 th
"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 s
[ 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 lo
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
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
rea
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
Hi,
On Mon, 26 Sep 2005, Tom Lane wrote:
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 7.3, at le
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 because the API of
heap_fetch() would need to change from what i
27 matches
Mail list logo