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...
The biggest problem is going to be moving changes on the 2.2.x branch
forward to trunk. This was extremely difficult with 2.1.x, and I'm
betting its going to be quite difficult with 2.2->2.3. But, I think
the 2.3 changes are going to be focused enough that we can really work
on improving a lot of places around the edges. I think we should
really define where the changes are taking place on 2.3 so we don't
step on each other. With a few rules and good communication, I think
we can minimize the pain of moving the changes forward.
Indeed. I should step back on write an article on what is happening with
geotools and how 2.3.x
helps us get there.
If geotools does make 2.2.x the 'new official stable branch' then I'm
willing to put the time into make a "Geoserver 1.3.0-Experimental"
release for people to test the current geoserver with the new geotools
stable branch. Once we've had a few people give it a good kick and
done some in-depth testing (and they all give two thumbs up), we'll
make that the new Geoserver trunk (then start looking at the geoserver
1.4.x changes).
Well there is no question that 2.2.x is the new stable branch, uDig
needs it to be (and we represent
a sizable body of developers). Having a Geoserver 1.3.0-Experimental to
help would be great, if
I could also ask that 1.3.0 Experimental include justins plugin system,
I kinda need both these bits of
the puzzel so GeoServer based work where I am now does not have branch
GeoServer code
(aka build rather then fork).
(This is, assuming (confirmed by a few people), that most of the
2.1.x->2.2.x changes are 'syntactical' as opposed to 'conceptual'.)
There is one bad change, a few interfaces were done as classes. This was
a case of poor QA on
previous releases. So you will need to use a FilterFactoryFinder, I
stressed about this back
in November. So yeah when we screw up there is pain :-(
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
