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. Each major new
RnD effort that merges in is a 2.x release. So the only real
instability should be when the merge takes place, which should hopefully
be no more than a week or two. Then uDig and GeoServer put it in their
unstable branches, put a release out, and get people using it. There
really should only be one new area of instability for each release. And
the window for 'minor' improvements that do affect the api should be
pretty small, like a week before the merge and a few weeks after, before
we lock the experimental branch down for stability.
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?
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...
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.
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.
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).
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.
Also note that GeoServer developers have tested and used 2.2.x
extensively, Simone and Alessio have always been working against it, and
Alex has been using their work in production, with no complaints, indeed
a few improvements since they're using HSQL for epsg, which seems to be
working well.
Thanks for taking leadership on this Dave, it's great to have you back.
Chris
(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
--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
