Good thoughts, gabriel.
I guess we need to figure out when the 1.4 branch will start and what
will be in it.
Here's some ideas:
Start a 1.4 branch that will:
a) track geotools 2.2 (trunk?) changes
b) add fixes to geotools 2.1.x and 2.2.x branches (!!)
c) new stuff to geotools 2.2 branches
d) start migrating the WCS stuff over (dont know whats required
here)
e) start migrating the WMS-raster stuff over (ditto)
f) add the new sco_complex stuff in (both geoserver and geotools)
We'll probably also have to maintain the 1.3.0 branch and make sure
changes in this branch get through to the 1.4 (both geoserver and
geotools changes).
** This means that Geoserver 1.4 is basically the "merge" version of all
the stuff thats currently NOT happening on trunk.
I dont think maintaining 2 geoserver branches is going to be very
difficult - almost all the "geoserver work" actually takes place in
geotools. For the current 1.3 stuff, the only major change (in the
actual geoserver codebase) over the last several months was adding in
support for SLD inline features (which was basically just adding a
FeatureTypeInfo sub-class). Gabriel's re-shuffle of classes in
Feb/March (?) is the other major thing.
Other changes (like the JAI removal), SLD Post, schema validation, and
updating for geotools api changes is pretty simple (lots of really
small things).
Has the WCS/WMS-raster stuff been mostly geoserver or Geotools work? My
understanding is that its pretty indepenent of the current geoserver
(with some obvious exceptions like in config).
Whatcha think?
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/