Thread: RE: [HACKERS] 6.6 release
Ok, if we go for a 6.6, then we will need to make sure the current
sources for JDBC are included in it (The stuff I have for 7.0 I've kept
separate).
I'll keep on plodding along with a "7.0" version of the driver, but I
won't commit anything until either 6.6 is out, or we decide that 7.0
would be imminent.
Peter
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, December 10, 1999 8:19 AM
To: Peter Mount
Cc: 'The Hermit Hacker'; Bruce Momjian; PostgreSQL-development
Subject: Re: [HACKERS] 6.6 release
Peter Mount <petermount@it.maidstone.gov.uk> writes:
> I'm also confused. So far, I've been working on the premise that the
> next release would be 7.0 because of the probably major additions
> expected, and that I'm hitting the JDBC driver hard to get as much of
> the 2.0 spec complete as is possible.
That was what I was thinking also, until yesterday. I think that the
proposal on the table is simply to consolidate/debug what we've already
done and push it out the door. If you've still got substantial work
left to finish JDBC 2.0, then it'd be better left for the next release.
I know I have a lot of little loose ends dangling on stuff that's
already "done", and a long list of nitty little bugs to fix, so it
makes sense to me to spend some time in fix-bugs-and-make-a-release
mode before going back into long-haul-feature-development mode.
Now, if other people don't have that feeling, maybe the idea of
a near-term release isn't so hot after all.
regards, tom lane
> > I'm also confused. So far, I've been working on the premise that the
> > next release would be 7.0 because of the probably major additions
> > expected, and that I'm hitting the JDBC driver hard to get as much of
> > the 2.0 spec complete as is possible.
OK, now *I'm* confused too! Peter, what in your stuff *requires* a
version renumbering to 7.0? The proposal was that we consolidate
changes in the backend server for a 6.6 release. Why does JDBC need to
wait for a "7.0" in the version number to support the 2.0 spec?
> That was what I was thinking also, until yesterday. I think that the
> proposal on the table is simply to consolidate/debug what we've already
> done and push it out the door. If you've still got substantial work
> left to finish JDBC 2.0, then it'd be better left for the next release.
Right.
> I know I have a lot of little loose ends dangling on stuff that's
> already "done", and a long list of nitty little bugs to fix, so it
> makes sense to me to spend some time in fix-bugs-and-make-a-release
> mode before going back into long-haul-feature-development mode.
> Now, if other people don't have that feeling, maybe the idea of
> a near-term release isn't so hot after all.
Yes I've got that feeling too!! :)
Marc, I'd like to understand why we are pushing 7.0 for this "release
where we are" release. We've (perhaps) got FK support, and a rewritten
psql, and lots of bug fixes, and maybe "join syntax" but not outer
joins. If we release as 7.0, then I'll force the date/time
reunification into this release, since it is a pretty big change to
the backend tables (I've been waiting quite a while already for the
major rev jump to do this).
But we won't have WAL, outer joins, rewritten query tree, etc etc so
why are we pushing the major rev jump now? imho rewriting the query
tree, which affects the parser, planner, optimizer, and perhaps
executor, is as invasive as we'll get; that and WAL should trigger
7.0.
btw, I'm not really happy with the prospect/suggestion of going from
7.0 to 8.0 in a short time period; one of things I'm most satisfied
with in our development is that we have significant minor releases and
that we haven't succumbed to the "major rev only" marketing driven
ploys of the big guys...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> Marc, I'd like to understand why we are pushing 7.0 for this "release > where we are" release. We've (perhaps) got FK support, and a rewritten > psql, and lots of bug fixes, and maybe "join syntax" but not outer > joins. If we release as 7.0, then I'll force the date/time > reunification into this release, since it is a pretty big change to > the backend tables (I've been waiting quite a while already for the > major rev jump to do this). One issue is that while we all want WAL and new query structure and stuff like that, we don't have end users asking for this repeatedly. What we do have them asking for is foreign keys. The major issue seems to be that the 7.0 release is going to have major incompatibilities for prior releases in the area of date types, and stuff like that. With all we are doing, I am not sure that is even going to work because we can't synchonize all the incompatibility stuff for one release. Maybe we just call it 7.0, and have some more incompatibility stuff in 7.1. Seems waiting for some .0 release is not going to work, unless we scrap the Feb 1 beta and just wait for all new stuff to be finished, but that seems worse than having a 7.1 that contains some incompatiblities. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, 10 Dec 1999, Thomas Lockhart wrote:
> Marc, I'd like to understand why we are pushing 7.0 for this "release
> where we are" release. We've (perhaps) got FK support, and a rewritten
> psql, and lots of bug fixes, and maybe "join syntax" but not outer
> joins. If we release as 7.0, then I'll force the date/time
> reunification into this release, since it is a pretty big change to
> the backend tables (I've been waiting quite a while already for the
> major rev jump to do this).
>
> But we won't have WAL, outer joins, rewritten query tree, etc etc so
> why are we pushing the major rev jump now? imho rewriting the query
> tree, which affects the parser, planner, optimizer, and perhaps
> executor, is as invasive as we'll get; that and WAL should trigger
> 7.0.
>
> btw, I'm not really happy with the prospect/suggestion of going from
> 7.0 to 8.0 in a short time period; one of things I'm most satisfied
> with in our development is that we have significant minor releases and
> that we haven't succumbed to the "major rev only" marketing driven
> ploys of the big guys...
FreeBSD (my role model, always has been) has two trees right now...4.0,
which is the development tree (ie. what I'm proposing as our 8.0), and,
currently, 3.3 for their stable tree. Anything new and wonderful goes
into 4.0...anything deemed "safe" gets back patched to 3.x and
periodically released.
The idea is that anyone can throw anything (within reason) into the 8.0
tree while we still have a stable branch to work on and make releases
on...so any "safe features" can be back-patched to 7.x.
Damn damn damn...I can never explain these things right. The 7.x would,
*at all times* maintain database compatibility with any 7.x release...I
could cvsup down the newest source, build and install it, without any risk
to my current databases...but still get access to a newer feature
set. After a few months of development, like now, we freeze the 7.x
branch and do up a release (7.1) that packages things up.
For instance, if you look at Hub, its running 3.4-RC right now...FreeBSD
just did a 'freeze' for a 3.4 release, and because Hub has its kernel
updated periodically through cvsup, the 'uname -a' output changes with...I
basically keep up with the latest *stable* version of FreeBSD on Hub, but
my home machine, using the same mechanism, runs 4.0-CURRENT, a totally
developmental/experimental version...
I think the project has gotten to such a size, and such a number of
developers, that this is feasible to do...we'd still have our major
releases, but only have minor, not minor.minor releases...
Instead of v6.5.1 after a month of v6.5 being released, we'd have released
v6.6 as being the more current stable version...its just taking things one
step further then what we've done recently with the release of v6.5.3...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Bruce Momjian wrote:
> One issue is that while we all want WAL and new query structure and
> stuff like that, we don't have end users asking for this repeatedly.
> What we do have them asking for is foreign keys.
>
> The major issue seems to be that the 7.0 release is going to have major
> incompatibilities for prior releases in the area of date types, and
> stuff like that. With all we are doing, I am not sure that is even
> going to work because we can't synchonize all the incompatibility stuff
> for one release.
>
> Maybe we just call it 7.0, and have some more incompatibility stuff in
> 7.1. Seems waiting for some .0 release is not going to work, unless we
> scrap the Feb 1 beta and just wait for all new stuff to be finished, but
> that seems worse than having a 7.1 that contains some incompatiblities.
Now that you say it,
not just maybe, definitely call it 7.0!
As said on the phone, the deferred trigger queue required for
the FOREIGN KEY stuff delays all AFTER ROW trigger for
execution at least past the entire statement.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> I think the project has gotten to such a size, and such a number of
> developers, that this is feasible to do...we'd still have our major
> releases, but only have minor, not minor.minor releases...
Hmm. Pretty sure I don't agree that we have enough developers to
handle this...
> Instead of v6.5.1 after a month of v6.5 being released, we'd have released
> v6.6 as being the more current stable version...its just taking things one
> step further then what we've done recently with the release of v6.5.3...
OK, I *think* I understand your suggestion. If that is the way the
project goes, OK, but I'm not happy about it, really. If we had been
doing this scheme since v6.0, we would have gone from v6.0 to v11.3 in
2.5-3 years, with (from my saved tarballs and the release notes):
v6.0 (6.0 series)
v7.0 (6.1 series)
v7.1
v8.0 (6.2 series)
v8.1
v9.0 (6.3 series)
v9.1
v9.2
v10.0 (v6.4 series)
v10.1
v10.2
v11.0 (6.5 series)
v11.1
v11.2
v11.3
Oh, btw, virtually no minor release has new features (since they all
preserve DB contents and structure), just fixes for code breakage.
I'd like to put dates on the releases, to point out that in several
instances we went from vX.0 to vX.1 in two to four weeks :(
Actually, this is the slippery road to name and version escalation: we
should have released "PostgreSQL+", "PostgreSQL Pro", "PostgreSQL
Developers Edition", "PostgreSQL++", "PostgreSQL II", "PostgreSQL
Pro+", etc by now ;)
That way, we can have a v2.0 of a bunch of products, and people will
think we're doing real development without ever checking that we are.
Works for other folks, but I don't see what it buys us.
OK, I've had a bit of fun with this, and I'll shut up now (well,
maybe), but I don't think that escalating our version numbering fixes
problems, and just means that we have a "R10" (a la "Y2K") problem
sooner rather than later.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > I think the project has gotten to such a size, and such a number of > > developers, that this is feasible to do...we'd still have our major > > releases, but only have minor, not minor.minor releases... > > Hmm. Pretty sure I don't agree that we have enough developers to > handle this... Agreed. > OK, I've had a bit of fun with this, and I'll shut up now (well, > maybe), but I don't think that escalating our version numbering fixes > problems, and just means that we have a "R10" (a la "Y2K") problem > sooner rather than later. Agreed. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Incompatibilities from one release to the next *has* to bump the major version...a minor number should be a *minor* upgrade, plain and simple... On Fri, 10 Dec 1999, Bruce Momjian wrote: > > Marc, I'd like to understand why we are pushing 7.0 for this "release > > where we are" release. We've (perhaps) got FK support, and a rewritten > > psql, and lots of bug fixes, and maybe "join syntax" but not outer > > joins. If we release as 7.0, then I'll force the date/time > > reunification into this release, since it is a pretty big change to > > the backend tables (I've been waiting quite a while already for the > > major rev jump to do this). > > One issue is that while we all want WAL and new query structure and > stuff like that, we don't have end users asking for this repeatedly. > What we do have them asking for is foreign keys. > > The major issue seems to be that the 7.0 release is going to have major > incompatibilities for prior releases in the area of date types, and > stuff like that. With all we are doing, I am not sure that is even > going to work because we can't synchonize all the incompatibility stuff > for one release. > > Maybe we just call it 7.0, and have some more incompatibility stuff in > 7.1. Seems waiting for some .0 release is not going to work, unless we > scrap the Feb 1 beta and just wait for all new stuff to be finished, but > that seems worse than having a 7.1 that contains some incompatiblities. > > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On 1999-12-10, The Hermit Hacker mentioned: > Damn damn damn...I can never explain these things right. The 7.x would, > *at all times* maintain database compatibility with any 7.x release...I > could cvsup down the newest source, build and install it, without any risk > to my current databases...but still get access to a newer feature In general, I like that concept, but I don't see that happening. With every third patch "requiring initdb" you would potentially stall certain areas of development indefinitely with your requirement. Unless we dream up some way to dynamically adjust outdated system catalogues ... -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
On 1999-12-10, Bruce Momjian mentioned: > Maybe we just call it 7.0, and have some more incompatibility stuff in > 7.1. Seems waiting for some .0 release is not going to work, unless we > scrap the Feb 1 beta and just wait for all new stuff to be finished, but > that seems worse than having a 7.1 that contains some incompatiblities. What kind of incompatibilities are we talking about here really? Is there anything that can't be resolved via * big warning signs * pg_dump or (to be created) friends * supporting the old stuff for a while as well * automated conversion of the things using the old stuff * informative documents outlining the reason of the change and how to cope with it? Things change all the time, that's a fact of life. If foreign keys get done this is definitely the greatest thing in the world for the end user, so 7.0 is a good name. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Incompatibilities is a simple concept..if it requires an initdb, its incompatible, period...if a pg_dump has to be performed, its incompatible...if it requires me to do more then a 'make install' and a restart of the server, its incompatible...if it requires me to recompile any of my binaries, its incompatible... Not all changes that are made require changes to system tables... On Sat, 11 Dec 1999, Peter Eisentraut wrote: > On 1999-12-10, Bruce Momjian mentioned: > > > Maybe we just call it 7.0, and have some more incompatibility stuff in > > 7.1. Seems waiting for some .0 release is not going to work, unless we > > scrap the Feb 1 beta and just wait for all new stuff to be finished, but > > that seems worse than having a 7.1 that contains some incompatiblities. > > What kind of incompatibilities are we talking about here really? Is there > anything that can't be resolved via > * big warning signs > * pg_dump or (to be created) friends > * supporting the old stuff for a while as well > * automated conversion of the things using the old stuff > * informative documents outlining the reason of the change and how to > cope with it? > > Things change all the time, that's a fact of life. > > If foreign keys get done this is definitely the greatest thing in the > world for the end user, so 7.0 is a good name. > > -- > Peter Eisentraut Sernanders v�g 10:115 > peter_e@gmx.net 75262 Uppsala > http://yi.org/peter-e/ Sweden > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Thomas Lockhart wrote: > > btw, I'm not really happy with the prospect/suggestion of going from > 7.0 to 8.0 in a short time period; one of things I'm most satisfied ^^^^^^^^^^ > with in our development is that we have significant minor releases and > that we haven't succumbed to the "major rev only" marketing driven > ploys of the big guys... I agreed! I propose to name the next release as 6.6 and the "WAL" release as 7.0 or 6.7, but not 8.0... Vadim
Vadim Mikheev wrote: > > Thomas Lockhart wrote: > > > > btw, I'm not really happy with the prospect/suggestion of going from > > 7.0 to 8.0 in a short time period; one of things I'm most satisfied > ^^^^^^^^^^ > > with in our development is that we have significant minor releases and > > that we haven't succumbed to the "major rev only" marketing driven > > ploys of the big guys... > > I agreed! I propose to name the next release as 6.6 ^^^ or 7.0 > and the "WAL" release as 7.0 or 6.7, but not 8.0... ^^^ and 7.1 Vadim
7.0 and 7.1 I could live with...
On Sun, 12 Dec 1999, Vadim Mikheev wrote:
> Vadim Mikheev wrote:
> >
> > Thomas Lockhart wrote:
> > >
> > > btw, I'm not really happy with the prospect/suggestion of going from
> > > 7.0 to 8.0 in a short time period; one of things I'm most satisfied
> > ^^^^^^^^^^
> > > with in our development is that we have significant minor releases and
> > > that we haven't succumbed to the "major rev only" marketing driven
> > > ploys of the big guys...
> >
> > I agreed! I propose to name the next release as 6.6
> ^^^
> or 7.0
>
> > and the "WAL" release as 7.0 or 6.7, but not 8.0...
> ^^^
> and 7.1
>
> Vadim
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Vadim Mikheev <vadim@krs.ru> writes:
>> I agreed! I propose to name the next release as 6.6
> ^^^
> or 7.0
>> and the "WAL" release as 7.0 or 6.7, but not 8.0...
> ^^^
> and 7.1
7.0 and 7.1 seem like the worst choice of names to me. We are not
planning any major new features for the Feb release (except for whatever
part of foreign key support Jan has working by then). There will be
some major new features for the release-after-that: WAL, some kind of
answer for the long-tuple problem, etc. etc. So it'd be very confusing
to users to call this one a "major" version bump, when it will have less
new stuff in it than the "minor" version bumps before and after.
I could live with 7.0 and then 8.0, if we were going to switch to
two-part instead of three-part version numbering. But I agree with
Thomas that I'd rather stick to the convention we have been using.
If we are going to be consistent with the way we have named prior
releases, it seems to me that there is no choice: the Feb release
is 6.6, and the one after it will be 7.0 (or maybe even 6.7).
I also would rather do it that way because I think the idea is to
wrap up *what we have now* and get it out. If we call the Feb release
7.0, then Thomas will want to cram in date/time type consolidation work
that (AFAIK) he hasn't even started on, and there'll be great temptation
to try to squeeze in other half-baked stuff in order to try to justify
calling this a major version bump. That's completely at odds with what
I thought the proposal of a near-term release was all about.
Basically, if people insist that the next release should be called 7.0,
I'd be inclined to forget about a near-term release and go back to
Plan A: keep working on it until we have enough stuff done to justify
calling it 7.0.
regards, tom lane
> Vadim Mikheev <vadim@krs.ru> writes:
> >> I agreed! I propose to name the next release as 6.6
> > ^^^
> > or 7.0
> >> and the "WAL" release as 7.0 or 6.7, but not 8.0...
> > ^^^
> > and 7.1
>
> 7.0 and 7.1 seem like the worst choice of names to me. We are not
> planning any major new features for the Feb release (except for whatever
> part of foreign key support Jan has working by then). There will be
> some major new features for the release-after-that: WAL, some kind of
> answer for the long-tuple problem, etc. etc. So it'd be very confusing
> to users to call this one a "major" version bump, when it will have less
> new stuff in it than the "minor" version bumps before and after.
>
> I could live with 7.0 and then 8.0, if we were going to switch to
> two-part instead of three-part version numbering. But I agree with
> Thomas that I'd rather stick to the convention we have been using.
> If we are going to be consistent with the way we have named prior
> releases, it seems to me that there is no choice: the Feb release
> is 6.6, and the one after it will be 7.0 (or maybe even 6.7).
>
> I also would rather do it that way because I think the idea is to
> wrap up *what we have now* and get it out. If we call the Feb release
> 7.0, then Thomas will want to cram in date/time type consolidation work
> that (AFAIK) he hasn't even started on, and there'll be great temptation
> to try to squeeze in other half-baked stuff in order to try to justify
> calling this a major version bump. That's completely at odds with what
> I thought the proposal of a near-term release was all about.
>
> Basically, if people insist that the next release should be called 7.0,
> I'd be inclined to forget about a near-term release and go back to
> Plan A: keep working on it until we have enough stuff done to justify
> calling it 7.0.
Let's look at the 7.0 features list:
Foreign Keys - Jan WAL - Vadim Function args - Tom System indexes - Bruce
Date/Time types - Thomas Optimizer - Tom
Outer Joins - Thomas? Long Tuples - ?
We have foreign keys and long tuples in Feb 1. Jan says on�long tuples:
I thought about the huge size variable text type a little more. And I think I could get the following
implementation to work reliable for our upcoming release.
The more we explore long tuples, it seems easier than expected.
Chaining tuples was going to be hard. The new way is more efficient, and
easier.
I assume Thomas may do the date/time for Feb 1 because it mostly
removing old types, I think.
So, we will not have WAL for Feb 1, but people are clammoring for
foreign keys and long tuples. I think 7.0 is good for Feb 1. We can add
WAL in 7.1.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Okay, this whole thread could continue going back and forth for the next 6 months and we may as well wait for WAL :) It is agreed that Feb 1st is the beta date...it will not include WAL, but will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels prepared with the WAL code... Altho I would personally like to get rid of the major.minor.minor numbering scheme, and just have it major.minor, the arguments against vs for outweigh, so we'll stick with what we've always had in that regard... On Feb 1st, the CVS repository will be branched, like we did on the last release, so that we can beta/debug 7.0 *without* interfering with development on 7.1. This has proven to work quite well with v6.5.x, as far as I'm concerned...since, once we go beta, there are to be no new features, only bug fixes, this shouldn't affect anyone, eh? :) On Sun, 12 Dec 1999, Bruce Momjian wrote: > > Vadim Mikheev <vadim@krs.ru> writes: > > >> I agreed! I propose to name the next release as 6.6 > > > ^^^ > > > or 7.0 > > >> and the "WAL" release as 7.0 or 6.7, but not 8.0... > > > ^^^ > > > and 7.1 > > > > 7.0 and 7.1 seem like the worst choice of names to me. We are not > > planning any major new features for the Feb release (except for whatever > > part of foreign key support Jan has working by then). There will be > > some major new features for the release-after-that: WAL, some kind of > > answer for the long-tuple problem, etc. etc. So it'd be very confusing > > to users to call this one a "major" version bump, when it will have less > > new stuff in it than the "minor" version bumps before and after. > > > > I could live with 7.0 and then 8.0, if we were going to switch to > > two-part instead of three-part version numbering. But I agree with > > Thomas that I'd rather stick to the convention we have been using. > > If we are going to be consistent with the way we have named prior > > releases, it seems to me that there is no choice: the Feb release > > is 6.6, and the one after it will be 7.0 (or maybe even 6.7). > > > > I also would rather do it that way because I think the idea is to > > wrap up *what we have now* and get it out. If we call the Feb release > > 7.0, then Thomas will want to cram in date/time type consolidation work > > that (AFAIK) he hasn't even started on, and there'll be great temptation > > to try to squeeze in other half-baked stuff in order to try to justify > > calling this a major version bump. That's completely at odds with what > > I thought the proposal of a near-term release was all about. > > > > Basically, if people insist that the next release should be called 7.0, > > I'd be inclined to forget about a near-term release and go back to > > Plan A: keep working on it until we have enough stuff done to justify > > calling it 7.0. > > Let's look at the 7.0 features list: > > Foreign Keys - Jan > WAL - Vadim > Function args - Tom > System indexes - Bruce > Date/Time types - Thomas > Optimizer - Tom > > Outer Joins - Thomas? > Long Tuples - ? > > We have foreign keys and long tuples in Feb 1. Jan says on�long tuples: > > I thought about the huge size variable text type a little > more. And I think I could get the following implementation > to work reliable for our upcoming release. > > The more we explore long tuples, it seems easier than expected. > Chaining tuples was going to be hard. The new way is more efficient, and > easier. > > I assume Thomas may do the date/time for Feb 1 because it mostly > removing old types, I think. > > So, we will not have WAL for Feb 1, but people are clammoring for > foreign keys and long tuples. I think 7.0 is good for Feb 1. We can add > WAL in 7.1. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> It is agreed that Feb 1st is the beta date...it will not include WAL, but
> will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels
> prepared with the WAL code...
OK, it's decided. Let's quit arguing.
> On Feb 1st, the CVS repository will be branched, like we did on the last
> release, so that we can beta/debug 7.0 *without* interfering with
> development on 7.1. This has proven to work quite well with v6.5.x,
Actually, I thought what worked well was to postpone the branch as long
as possible. Double-patching is no fun...
regards, tom lane
> The Hermit Hacker <scrappy@hub.org> writes: > > It is agreed that Feb 1st is the beta date...it will not include WAL, but > > will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels > > prepared with the WAL code... > > OK, it's decided. Let's quit arguing. > > > On Feb 1st, the CVS repository will be branched, like we did on the last > > release, so that we can beta/debug 7.0 *without* interfering with > > development on 7.1. This has proven to work quite well with v6.5.x, > > Actually, I thought what worked well was to postpone the branch as long > as possible. Double-patching is no fun... Ditto. Look at the 6_5 branch and you will see it was done far into the 6.5 release, not at the 6.5.0 release. I don't want to continue mentioning this for every release. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sun, 12 Dec 1999, Bruce Momjian wrote:
> > The Hermit Hacker <scrappy@hub.org> writes:
> > > It is agreed that Feb 1st is the beta date...it will not include WAL, but
> > > will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels
> > > prepared with the WAL code...
> >
> > OK, it's decided. Let's quit arguing.
> >
> > > On Feb 1st, the CVS repository will be branched, like we did on the last
> > > release, so that we can beta/debug 7.0 *without* interfering with
> > > development on 7.1. This has proven to work quite well with v6.5.x,
> >
> > Actually, I thought what worked well was to postpone the branch as long
> > as possible. Double-patching is no fun...
>
> Ditto. Look at the 6_5 branch and you will see it was done far into the
> 6.5 release, not at the 6.5.0 release. I don't want to continue
> mentioning this for every release.
The branch should be created on release, not after the release, else the
branch is useless...sorry, think I said something wrong
originally...didn't mean 'on beta', meant 'on release'...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Ditto. Look at the 6_5 branch and you will see it was done far into the > > 6.5 release, not at the 6.5.0 release. I don't want to continue > > mentioning this for every release. > > The branch should be created on release, not after the release, else the > branch is useless...sorry, think I said something wrong > originally...didn't mean 'on beta', meant 'on release'... No. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > The Hermit Hacker <scrappy@hub.org> writes: > > > It is agreed that Feb 1st is the beta date...it will not include WAL, but > > > will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels > > > prepared with the WAL code... > > > > OK, it's decided. Let's quit arguing. > > > > > On Feb 1st, the CVS repository will be branched, like we did on the last > > > release, so that we can beta/debug 7.0 *without* interfering with > > > development on 7.1. This has proven to work quite well with v6.5.x, > > > > Actually, I thought what worked well was to postpone the branch as long > > as possible. Double-patching is no fun... > > Ditto. Look at the 6_5 branch and you will see it was done far into the > 6.5 release, not at the 6.5.0 release. I don't want to continue > mentioning this for every release. 6_5 branch was after 6.5.1 release. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> Ditto. Look at the 6_5 branch and you will see it was done far into the
>>>> 6.5 release, not at the 6.5.0 release. I don't want to continue
>>>> mentioning this for every release.
>>
>> The branch should be created on release, not after the release, else the
>> branch is useless...sorry, think I said something wrong
>> originally...didn't mean 'on beta', meant 'on release'...
> No.
Bruce is right: we should delay making a branch for REL7_0 patches
until people are ready to start committing new features for 7.1.
I'm guessing that would be a month or two after formal release of 7.0.
We did that after the 6.5 release (IIRC, we didn't make the branch
until around the time of 6.5.2) and I thought it worked just great;
saved a lot of double-patching.
regards, tom lane
> Incompatibilities from one release to the next *has* to bump the major
> version...a minor number should be a *minor* upgrade, plain and simple...
Fine. But I'm happy with "minor" Postgres improvements counting as
"major" for other packages. We're doing a better job then lots of
commercial companies in improving the product; I'd hate to try
matching some of their pathetic release bumps in our version numbering
since by that standard we should be *skipping* some of the whole
numbers.
Lets see,
Solaris 2.7 == SunOS 5.5 (or is it 5.4?) == Solaris 7
JDK1.2 == Java1.2 == Java 2
Win98 != Win98 Rel2 != Win98 Rel2 Hotfix x != ...
Yuck.
imo the *only* reason we are tempted to do more major releases is that
we are too lazy/understaffed/sensible (you pick it) to support
multiple db formats for our compiled code. Other commercial DBs don't
release often, and they don't include big improvements, but they *do*
include support for multiple db formats/schemas in their product, so
you aren't forced into an initdb for each release. Instead they
include klugy workaround code to allow reading older formats with the
newer version.
Good things are being said about us, and people are noticing that the
product has improved from v6.0 to v6.5. We don't need to be at v11.0
to get noticed; in fact it may look a little silly...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart wrote: > > Good things are being said about us, and people are noticing that the > product has improved from v6.0 to v6.5. We don't need to be at v11.0 > to get noticed; in fact it may look a little silly... Agreed again! I would be happy with 6.X up to 6.9 -:) Vadim
On Tue, 14 Dec 1999, Vadim Mikheev wrote:
> Thomas Lockhart wrote:
> >
> > Good things are being said about us, and people are noticing that the
> > product has improved from v6.0 to v6.5. We don't need to be at v11.0
> > to get noticed; in fact it may look a little silly...
>
> Agreed again! I would be happy with 6.X up to 6.9 -:)
At an ~2year development cycle for each major, it would take us ~6 years
to attain v10...I think we are safe :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Fri, 10 Dec 1999, Thomas Lockhart wrote: > imo the *only* reason we are tempted to do more major releases is that > we are too lazy/understaffed/sensible (you pick it) to support > multiple db formats for our compiled code. Other commercial DBs don't > release often, and they don't include big improvements, but they *do* > include support for multiple db formats/schemas in their product, so > you aren't forced into an initdb for each release. Instead they > include klugy workaround code to allow reading older formats with the > newer version. Then why don't we come up with something to autoconvert the user's databases without having to dump/initdb/reload? Or is that just not feasable (impossible's an answer I'd find hard to believe, but more trouble than it's worth is understandable). Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> On Fri, 10 Dec 1999, Thomas Lockhart wrote: > > > imo the *only* reason we are tempted to do more major releases is that > > we are too lazy/understaffed/sensible (you pick it) to support > > multiple db formats for our compiled code. Other commercial DBs don't > > release often, and they don't include big improvements, but they *do* > > include support for multiple db formats/schemas in their product, so > > you aren't forced into an initdb for each release. Instead they > > include klugy workaround code to allow reading older formats with the > > newer version. > > Then why don't we come up with something to autoconvert the user's > databases without having to dump/initdb/reload? Or is that just > not feasable (impossible's an answer I'd find hard to believe, but > more trouble than it's worth is understandable). System table changes often make that difficult. pg_upgrade does most of what we want by keeping the disk tables and allowing initdb. If we don't change the on-disk structure of user tables, pg_upgrade allows quick upgrades. Not sure 7.0 will allow the use of pg_upgrade. 6.5 did not because the on-disk table structure changed with MVCC. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Is there a writeup of the version numbering and CVS branch scheme in any of the FAQs? If not, there should be. Steve Bruce Momjian wrote: > > The Hermit Hacker <scrappy@hub.org> writes: > > > It is agreed that Feb 1st is the beta date...it will not include WAL, but > > > will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels > > > prepared with the WAL code... > > > > OK, it's decided. Let's quit arguing. > > > > > On Feb 1st, the CVS repository will be branched, like we did on the last > > > release, so that we can beta/debug 7.0 *without* interfering with > > > development on 7.1. This has proven to work quite well with v6.5.x, > > > > Actually, I thought what worked well was to postpone the branch as long > > as possible. Double-patching is no fun... > > Ditto. Look at the 6_5 branch and you will see it was done far into the > 6.5 release, not at the 6.5.0 release. I don't want to continue > mentioning this for every release. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************
> Is there a writeup of the version numbering and CVS branch scheme > in any of the FAQs? There is no item because there isn't a standard yet. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026