On Saturday 29 January 2005 11:33, Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > I'm not mischarecterizing, I just feel that putting out an lru based
> > 8.0.x release is such a bad idea that I'd rather do (1) than gamble on
> > (2).
>
> I don't understand why you think it's such a bad idea. We do have the
> problem of getting adequate testing, but I think the answer to that
> is to put the same patch into HEAD as well.
>
The combination of inadequate testing, making support more difficult, and
general all around confusion that beta/rc's for a revision level release are
sure to cause. Not to mention that if the patent ever does materialize into a
problem, the scope of that problem will be that much greater the longer we
wait.
> > We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a
> > 12 month dev for 8.2 and go about things.
>
> I will resist that idea strongly. We have no experience as a community
> with managing multiple active development branches, and I feel certain
> that we'd mess it up (eg, commit things into the wrong branch, or fail
> to commit things into both branches that need to be in both). Case in
> point: Teodor has already, without discussion, committed 8.1 changes in
> tsearch2 that should force an initdb. If we were taking the idea of a
> backward-compatible 8.1 seriously we'd have to make him back that out of
> 8.1.
I think this is a false case since right now we are hanging in limbo, with
people unsure of what is proper to commit into what branch. If there had
been an official announcement that no initdb level changes were to go into
8.1 I think we'd be ok.
> I can't see trying to ride herd on all the committers to make sure
> no one unintentionally breaks file-level compatibility over a whole dev
> cycle, even a short one.
>
I think the key is to put someone in charge of either 8.1 or 8.2 and let them
be the primary gatekeeper for that release. It can work either way... people
develop against 8.1 and we have an 8.2 gatekeeper(s) responsible for patching
forward any new commits into 8.2 and handling file-level incompatible feature
commits. Conversly we can have folks develop against 8.2 and have someone in
charge of backpatching any non file-level incompatible changes backwards and
the ARC changes.
There are other upsides to this as well. If we could do this now it would
help move us to the ability to keep feature development going year round.
Rather than having to stop 4-5 months every year to do beta we could create a
new branch during beta and let people continue on with that... we already had
some rumblings of that idea during the 8.0 beta cycle, this would give us a
good test run.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
