Re: Patent issues and 8.1

On Wed, 2005-01-26 at 02:09, Neil Conway wrote:
> Tom Lane wrote:
> > This may be the right path to go for
> > 8.0.* ... but we must NOT suppose that we can just push it out without
> > a full beta test cycle.
> 
> Yeah, I think a beta period would be a good idea (not nearly as long as 
> the 8.0 beta period was, though).
> 
> I think it would be better to have a few weeks of beta prior to 8.0.2 
> and resolve the problem here and now, rather than crippling the 8.1 
> cycle (as the no-initdb policy would) or waiting for the problem to 
> *really* become serious (as the "no action needed now" policy would).
> 

I don't think it is worth breaking the expectation that only minor
changes get committed in revision level releases even with a beta. I
especially hate to think about support and tuning information that has
the potential to be quit different depending on if your running 8.0.1 or
8.0.2 or some such division. 

I still feel a better plan is to use the short dev cycle for 8.1 to
replace ARC and include any non-initdb changes and to branch an 8.2 now
if people with initdb changes don't want to wait to do further
development. This allows people to move away from arc using a proper
release with out having to do dump/reload; certainly the path of least
resistance for users. It is also cleaner for folks in non-patent
countries.  

Of course this isn't something that has to be fixed in the next 4
months... if enough initdb level changes are close now, we could commit
to a 6 month initdb/arc replace dev cycle followed by a 3 month beta for
8.1 and release before the end of the year. That might be best anyway
since I think we probably have 3-4 major changes already waiting to go
that can certainly be finished within 6 months (2PC, autovacuum, Devrims
work, ARC replacement, potential pitr replication changes) which would
be plenty enough to warrant a new release. It's not as good as the
8.1/8.2 plan but better than the 8.0.x plan (IMHO). 


Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL