Chris Holmes wrote:
Jody Garnett wrote:
The plan would be to keep the 2.2.x branch the "stable" branch until
"2.3" is solid and ready to be the new "stable."
I would actually like to get to 2.3.x as soon as possible, and with
uDig and GeoServer working towards it
we could shorten this down to the 4 to 6 month range. Initial 2.3
based GeoServer milestone is set for
next month I think...
I think we were thinking/hoping maybe even shorter. The suggestion
from awhile ago, which we are steadily moving towards, is to make
trunk much more stable by doing all experimental work in a branch.
Understood Chris, I was more meaning that right now a significant
portion of the developers are locked away in branches. If both teams
came out of RnD branches to help out we will go through it quicker.
However the 4 to 6 month range still stands - there is documentation to do.
Also, one note, when you say this Jody:
> - 2.3.M1 is stretching everything to it limit as we revise the heart
> of geotools (hold on Justin)
You just mean the feature stuff right? No more api changes except
feature?
Isn't that enough? Feature is the foundation of spatial everything ;-)
So yeah "just" feature ....
Also could we get an update on the state of Filter? I think a filter
revision would ideally be it's own 2.x release, but I know some work
has been hitting on it...
Chris Filter is done, and is on trunk. There is a reason why it is not
its own milestone release -
Just the Filter change by itself does not paint a complete picture, it
is not something that is
consistent enough that we can document it.
GeoTools need three legs to stand on:
- data model
- query system
- opperations and services (like renderering)
2.2 reviewed the rendering side (and fell over the
factory/builder/container issues)
2.3.M0 updated the query system
2.3.M1 updates the data model
If we want we can start the documentation work now, the feature model
API is stable.
Indeed. I should step back on write an article on what is happening
with geotools and how 2.3.x
helps us get there.
That would be great Jody. I agree that we should have more
communication, maybe have reports from developers on what they worked
on each week. Though to give this teeth we should have a developer
who watches the commit list and asks people about it when they're not
talking.
Well I kinda liked the module maintainer idea with weekly IRC meetings,
call me a traditionalist ;-)
I think this would be great. We could do something like call this
GeoServer 1.5, as the half way point to GeoServer 2.0 (which would be
complex feature stuff, what we're currently calling 1.4), in the
tradition of Firefox and Tomcat with the .5 releases. Indeed when we
get the coverage stuff in that could be GeoServer 3.0 - we should not
fear version increases, it actually looks good from a 'marketing'
perspective.
Lets sort that out in a geoserver IRC meeting, where the effected
parties attend. I don't want to second guess RobA again (see last point
about communication).
Thanks for the discussion Chris/Dave.
Jody
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
