Good point Martin;
I have created the following jira QA blocker against 2.4.0 to ensure the
@since and other QA checks are dealt with before 2.4.0 goes out the door:
- http://jira.codehaus.org/browse/GEOT-1063
> Could it be that the trouble in building Geoserver against
> Geotools-trunk is parti
We also had a policy of adopting GeoAPI interfaces when they were
available; this habit broken when GeoAPI moved too quickly for us to
keep up when the go-1 renderer was introduced. I would try and reword
this to adopt official GeoAPI interfaces (ie that have been through the
review process); t
Andrea Aime a écrit :
> I guess you're referring to Sun's way of doing things, is it documented
> anywhere? Or is it just:
> * mark operations as deprecated for one release before removing;
> * mark release an API has been introduced into using @since
> * make sure interfaces do not change over tim
Andrea Aime ha scritto:
>* major changes and additions shall be approved by PMC
Ah, these major changes discussions could be the subject of a GSIP
like document, the Geoserver Improvement Proposals:
http://docs.codehaus.org/display/GEOS/GeoServer+Improvement+Proposals
at least it provides a
Jody Garnett ha scritto:
> Saul Farber wrote:
>>> I am actually hoping this reduces code branches ... both for geotools
>>> and geoserver.
>> So what do you see as the geoserver branch/functionality structure?
> At a certaint level geotools needs to not care what geoserver
> branch/functionality
Martin Desruisseaux ha scritto:
> Could it be that the trouble in building Geoserver against Geotools-trunk is
> partially caused by ourself not following our "API change" policy with enough
> discipline? I saw some public methods where the signature was changed instead
> of
> adding a new meth
Saul Farber wrote:
>> I am actually hoping this reduces code branches ... both for geotools
>> and geoserver.
> So what do you see as the geoserver branch/functionality structure?
At a certaint level geotools needs to not care what geoserver
branch/functionality structure is - only that they are
Could it be that the trouble in building Geoserver against Geotools-trunk is
partially caused by ourself not following our "API change" policy with enough
discipline? I saw some public methods where the signature was changed instead
of
adding a new method and deprecating the old one. It also se
>> I am not sure that suggestion (which occurred to me as well) is quite
>> strong enough - we are operating with this right now except the branch
>> of geoserver is called OWS4.
>>
>
> Sort-of. Except that OWS4 is just a one-man experiment.
> geoserver-track-gttrunk (better name, I think
Ok, so I just re-read my words below. Perhaps this is a slightly too
convoluted process to adopt as a legit development procedure.
I still think it would technically work, but I'm less sure of it than I
was when I thought of it. Maybe it's a good band-aid, but it's still
just a band-aid over
> I am actually hoping this reduces code branches ... both for geotools
> and geoserver.
So what do you see as the geoserver branch/functionality structure?
Leaving aside legacy branches that get only bugfix treatment (1.3.x,
soonish 1.4.x), how can geoserver lay out its braches to meet its
fu
Saul Farber wrote:
> I also wrote a long one, but have distilled it here.
> Pros: GSIP#6 is clearly a good idea. Why is gt-trunk out there if
> not to be used?
> Cons: Having many branches of code around makes bugs really hard to
> close because you have to patch the same damn thing once for e
I'm sure everyone's typing madly right now!
I also wrote a long one, but have distilled it here.
Pros: GSIP#6 is clearly a good idea. Why is gt-trunk out there if not
to be used?
Cons: Having many branches of code around makes bugs really hard to
close because you have to patch the same damn
Back in September I put out a GTSteering document with a couple of ideas
on how we could improve our game to support the applications that make
use of GeoTools. Some of those ideas came to a head today during the
GeoServer meeting.
What I would like to do is have GeoServer trunk and uDig trunk
14 matches
Mail list logo
