On Fri, 3 Oct 2003, Andrew Sullivan wrote:
> On Thu, Oct 02, 2003 at 02:15:33PM -0500, Bruno Wolff III wrote:
> > It might be better to split into two different trees. One just gets bug fixes,
> > the other gets bug fixes plus enhancements that won't require an initdb.
>
> Yes, please. Please, please do not force all users to accept new
> features in "stable" trees.
I wanted to say something similar earlier in this thread.
To me the stable branches are not for feature introduction. If features are
going to be introduced it is better to not have them applied in a manner which
means a pure bug fix only version can't be obtained. Obviously this means
having two branches if features are going to be introduced.
I agree sometimes one looks at new developments and thinks how good it would be
to have that feature, imagine what it'll be like when tablespaces are
introduced and you're using the previous stable version, but those features
need to be kept separate from the version that fixes that particularly nasty
index corruption someone only provided a fix for 12 months after the version
you have based your system around was released. One could argue that what is
really needed is a collection of patches providing a pick and choose facility
for features, with dependecies where unavoidable of course. The patches being
applicable to the latest bug patched version of the stable branch.
As an example take tsearch2. If that were core code, not optional, contrib
material, and one was running a 7.3 series server but wanted the nifty features
of tsearch2 instead of tsearch, would you expect all people upgrading within
the stable 7.3 branch for bug fixes to be forced to use tsearch2 and not
tsearch?
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
