[postgis-devel] Query interruptibility in stable branch
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Fri Jun 8 06:07:46 PDT 2012
On 06/06/12 16:08, Paul Ramsey wrote:
> I have no objection to code that is #defined as disabled being added.
> In fact I wanted to add some (the new rtree splitting approach prior
> to 2.0) recently. That being said, why not just maintain a branch at
> github with your changes for client purposes? I've done that (actually
> SVN spikes) many times in the past for folks on MapServer features.
>
> P.
Eh? This is actually the worst of both worlds because if it's disabled
by default then it won't get the testing it requires, plus we've
regressed to having more version-specific #ifdef-ery around. The reason
I worked so hard around 1.4 to improve version detection and make
dependencies compulsory was give users a more consistent experience, and
thus ensure that once a patch passes regression, it's going to be
reasonably safe.
While you could argue that this is not a bad thing, our track record on
getting this right isn't great - I've lost count of the number of times
during the 2.0 release cycle where I've had to fix #ifdef
POSTGIS_GEOS_VERSION ... #endif on older GEOS versions we've said we
support because they had been added but people obviously hadn't bothered
to compile-test them.
Honestly - please let's just keep this in 2.1 branch and enable it by
default there so it starts to get more testing. I've already conceded
that we should have a short 2.1 development cycle so that you can get
your RTree splitting changes in too. By putting new things in stable
releases, we are just working against ourselves and making all our lives
more difficult.
ATB,
Mark.
More information about the postgis-devel
mailing list