From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'The Hermit Hacker'" <scrappy(at)hub(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] 6.6 release |
Date: | 1999-12-10 15:43:31 |
Message-ID: | 38511FA3.38B9A5E1@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 1999-12-10 15:56:28 | Re: [HACKERS] FOREIGN KEY and shift/reduce |
Previous Message | Tom Lane | 1999-12-10 15:41:12 | Re: [HACKERS] insert using select with limit |