Tom Lane <[EMAIL PROTECTED]> writes:
> Huh? That is exactly counter to most people's expectations about
> version numbering. N.0 is the unstable release, N.1 is the one
> with some bugs shaken out. If we release a 7.5 people will expect
> it to be less buggy than 7.4, and I'm not sure we can pr
Christopher Browne <[EMAIL PROTECTED]> writes:
> I think that the set of new features here will fairly likely warrant
> the "8.0" moniker; the 'consistent' way to go would be to call this
> version 7.5, and then 8.0 would soon follow, and be the release where
> some degree of improved "maturity" ha
Christopher Browne wrote:
After takin a swig o' Arrakan spice grog, Gaetano Mendola <[EMAIL PROTECTED]> belched
out:
Peter Eisentraut wrote:
Alvaro Herrera wrote:
What was the rule for increasing the first number after just before
7.0?
That was just to avoid having to release a 6.6.6, which Jan
After takin a swig o' Arrakan spice grog, Gaetano Mendola <[EMAIL PROTECTED]> belched
out:
> Peter Eisentraut wrote:
>
>> Alvaro Herrera wrote:
>>
>>>What was the rule for increasing the first number after just before
>>>7.0?
>> That was just to avoid having to release a 6.6.6, which Jan had
>> cl
Peter,
> Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
Even better, we can have two different, parallel version numbers, so that the
next version can be 7.5 *and* 13.0.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast
On Sun, 1 Aug 2004, Peter Eisentraut wrote:
Alvaro Herrera wrote:
What was the rule for increasing the first number after just before
7.0?
That was just to avoid having to release a 6.6.6, which Jan had clearly
been working towards. :-)
Seriously, major version jumps correspond to epoch-like change
On Sat, Jul 31, 2004 at 22:40:52 -0700,
Steve Atkins <[EMAIL PROTECTED]> wrote:
>
> 8.0.0 suggests, to my customers at least, a brand new release with
> either massive re-architecting, many new features or both and that's
> likely to be riddled with bugs. While it would be unlikely that we'd
> s
Peter Eisentraut wrote:
Alvaro Herrera wrote:
What was the rule for increasing the first number after just before
7.0?
That was just to avoid having to release a 6.6.6, which Jan had clearly
been working towards. :-)
Seriously, major version jumps correspond to epoch-like changes, like
when the
Joshua D. Drake wrote:
Hello,
Version 7.5 is as close to a major release as I have seen in the almost
9 years I have been using PostgreSQL.
This release brings about a lot of "enterprise" features that have been
holding back PostgreSQL in a big way for
for a long time.
All of my serious customer
On Sun, Aug 01, 2004 at 12:20:59PM +0800, Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single
> >>release before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even
Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single release
> >>before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
> >>momentous. If this isn't 8.0,
This is more features worth mentioning than we've ever had in a single release
before -- and if you consider several add-ons which have been
implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
momentous. If this isn't 8.0, then what will be?
I tend to agree, and was
So, as far as you're concerned, there will never ever be an 8.0.
Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
How about 7.5i :)
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index sc
Hello,
Version 7.5 is as close to a major release as I have seen in the almost
9 years I have been using PostgreSQL.
This release brings about a lot of "enterprise" features that have been
holding back PostgreSQL in a big way for
for a long time.
All of my serious customers; potential, existi
I am fine with either numbering, but I think the 8.0 might make more
sense.
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> What was the rule for increasing the first number
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> What was the rule for increasing the first number after just before
>> 7.0?
> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)
AFAIR, we had informally been referring to tha
Josh Berkus <[EMAIL PROTECTED]> writes:
> Even if Savepoints don't make it, we'll still have:
Savepoints are in, as is exception-trapping in functions (at least
plpgsql, the other PLs are on their own :-().
Some other major improvements you didn't mention:
Cross-datatype comparisons are indexabl
Alvaro Herrera wrote:
> What was the rule for increasing the first number after just before
> 7.0?
That was just to avoid having to release a 6.6.6, which Jan had clearly
been working towards. :-)
Seriously, major version jumps correspond to epoch-like changes, like
when the code moved out of B
Josh Berkus wrote:
> So, as far as you're concerned, there will never ever be an 8.0.
Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TI
On Sun, Aug 01, 2004 at 12:02:47AM +0200, Peter Eisentraut wrote:
> Josh Berkus wrote:
> > > We've also never had a single release before that had its version
> > > number jump determined by the number of features.
> >
> > That's a non-argument, Peter; we don't have any clear criteria for
> > versi
Peter,
> Oh yes, we have very clear criteria: For patch releases, we increase the
> third number, for feature releases we increase the second number and
> set the third number to zero. Clear enough?
So, as far as you're concerned, there will never ever be an 8.0.
--
Josh Berkus
Aglio Database
Josh Berkus wrote:
> > We've also never had a single release before that had its version
> > number jump determined by the number of features.
>
> That's a non-argument, Peter; we don't have any clear criteria for
> version number jump.
Oh yes, we have very clear criteria: For patch releases, we i
Peter,
> We've also never had a single release before that had its version number
> jump determined by the number of features.
That's a non-argument, Peter; we don't have any clear criteria for version
number jump.
--
Josh Berkus
Aglio Database Solutions
San Francisco
Josh Berkus wrote:
> This is more features worth mentioning than we've ever had in a
> single release before
We've also never had a single release before that had its version number
jump determined by the number of features.
> I talked to a few of our people at OSCON who agreed with me. We'd
>
Folks,
Well, we're past feature freeze and with one reservation we know what's in the
next version. After talking to several people at OSCON, I want to revive a
discussion: whether this is 7.5 or 8.0. We tabled that discussion in April
pending a feature list.
Even if Savepoints don't make
25 matches
Mail list logo
