-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Migration is really only half the story, or not even that much. Every
> time you move to a new Postgres version you have to do extensive work
Robert Haas wrote:
Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
they necessarily want to, but they can't easily afford the downtime to
upgrade. Cutting them off arbitrarily early won't win us any friends. Once
pg_migrator (or better, in-place upgrades) is working
Robert Haas wrote:
> > Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because
> > they necessarily want to, but they can't easily afford the downtime to
> > upgrade. Cutting them off arbitrarily early won't win us any friends. Once
> > pg_migrator (or better, in-place upgrades)
Dave Page wrote:
> On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane wrote:
>>
>> ... 8.1 in RHEL5 ...
+1 for letting 7.* and 8.0 die whenever no-one's
motivated to bother supporting it anymore.
> Presumably you'll be on the hook until 2014 for 8.1 security patches
> I can't see the community wanting to
On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane wrote:
> Mark wrote:
>> Doesn't mean that packagers have to make new packages ... I personally
>> think new packages shouldn't be made for anything older then *maybe* 3
>> releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit
>> e
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Mark wrote:
> Doesn't mean that packagers have to make new packages ... I personally
> think new packages shouldn't be made for anything older then *maybe* 3
> re
Tom Lane wrote:
Greg Smith writes:
What I was trying to suggest was that right now, there are situations
where a new deployment on 8.1 is still completely reasonable and
possible to justify in the Enterprise Linux space, whereas I don't know
of any situation where 7.4/8.0 can be similarly
On Tue, 2009-12-01 at 17:14 -0500, Tom Lane wrote:
> However, if you are paying attention to what has shipped in
> recent Fedora releases, it's not hard to figure out that it will have
> PG >= 8.4.
I thought RHEL 6 would ship with 8.3. It will be perfect if it skips
8.3.
--
Devrim GÜNDÜZ, RHCE
Co
Greg Smith writes:
> What I was trying to suggest was that right now, there are situations
> where a new deployment on 8.1 is still completely reasonable and
> possible to justify in the Enterprise Linux space, whereas I don't know
> of any situation where 7.4/8.0 can be similarly defended as a
Tom Lane wrote:
Well, actually, if it's just "what will RH support", I just today got
launch commit on this...
What I was trying to suggest was that right now, there are situations
where a new deployment on 8.1 is still completely reasonable and
possible to justify in the Enterprise Linux sp
Tom Lane wrote:
Greg Smith writes:
Some people consider the extended support and easy upgrades of the RHEL5
versions valuable enough that they have a strong preference to use the
version of PostgreSQL that ships with it. Right now, when such people
ask me about using 8.1 in that context
Greg Smith writes:
> Some people consider the extended support and easy upgrades of the RHEL5
> versions valuable enough that they have a strong preference to use the
> version of PostgreSQL that ships with it. Right now, when such people
> ask me about using 8.1 in that context, I tell them w
Tom Lane wrote:
Personally I'll still be on the hook for maintaining 8.1 in RHEL5
so I'd be just as happy to keep it alive a bit longer, but if the
community doesn't want to deal with it that makes perfect sense.
Some people consider the extended support and easy upgrades of the RHEL5
version
Andrew Dunstan writes:
> The time between these periodic debates seems to be getting shorter and
> shorter.
No, this is just a continuation of the unresolved thread from a month or
so ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Scrappy wrote:
is there a reason why we can't follow a similar 4+3 life cycle?
packagers r produced for the first 4y after .0 release and only source
updates for year 5 thru 7?
if we could advertise such on the web, there would be no question as
to when bug reports are accepted (n+4y) and
is there a reason why we can't follow a similar 4+3 life cycle?
packagers r produced for the first 4y after .0 release and only source
updates for year 5 thru 7?
if we could advertise such on the web, there would be no question as
to when bug reports are accepted (n+4y) and when only secu
"Marc G. Fournier" writes:
> What are RedHats "EOL" dates for the various releases?
Dave already mentioned a public page for that:
http://www.redhat.com/security/updates/errata/
Based on track record so far, Red Hat isn't going to care about anything
but high-priority security issues towards the
On Tue, 1 Dec 2009, Tom Lane wrote:
"Greg Sabino Mullane" writes:
This thread never got resolved. I think we can all agree that EOL
for 7.4 is a "when", not an "if"? Can we get -core to take a stance
here and pick a date? I like the clean smooth lines of January 2011,
and thus saying that 2010
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> This thread never got resolved. I think we can all agree that EOL
>> for 7.4 is a "when", not an "if"? Can we get -core to take a stance
>> here and pick a date? I like the clean smooth lines of January 2011,
>> an
"Greg Sabino Mullane" writes:
> This thread never got resolved. I think we can all agree that EOL
> for 7.4 is a "when", not an "if"? Can we get -core to take a stance
> here and pick a date? I like the clean smooth lines of January 2011,
> and thus saying that 2010 is the last year in which we'll
20 matches
Mail list logo
