[Geoserver-devel] [PSC] Which gt2 version for GeoServer trunk?

GeoServer GeoServer Developer
1

Hi,
in yesterday's meeting we discussed which version of GeoTools
should GeoServer follow, gt2 2.5.x or trunk. Both have
pros and cons.
- 2.0.0 should be a new UI and new config release, no real
   new functionality, staying on 2.5.x would allow us to
   progress faster
- if we want to release 2.0.0 "soon", we'll have to cut
   gt2 2.6.0 as well... not sure it will be in a releasable
   state then (think style changes, not sure what else
   is boiling up there)
- on the other side, abandoning trunk means we have no
   control on what's going on there, meaning that we might
   have to deal with all headaches at once the moment
   we finally decide to switch

So, what will it be? PSC, we need a decision.
All things considered, having gt2 trunk go wild scares
me more than having to deal with the occasional issues
due to living on trunk but the ability to release
2.6.0 in time concerns me quite a bit.

I've asked on the gt2 channel about what will the 2.6.0
major change be, hopefully that will shed some light
on this last concern.

Opinions?
Cheers
Andrea

2

Andrea I am starting up a major (and short term) project on uDig trunk - with a deadline in October. So I cannot afford to have geotools trunk go crazy either. Jesse also wants to demo uDig trunk at FOSS4G which I think agrees with the GeoServer 2.0 timeline?

So, what will it be? PSC, we need a decision.
  

So as a GeoServer PSC the question for me comes down to exactly what the scope is for 2.6.0 - if it is just a race to get the wicket UI ready in time for demo at FOSS4G in september I am going to be tempted to recommend staying with GeoTools 2.5.0 (yes I understand that this is a bad long term risk management move; and I also understand it would really hurt my above mentioned uDig project).

All things considered, having gt2 trunk go wild scares me more than having to deal with the occasional issues due to living on trunk but the ability to release 2.6.0 in time concerns me quite a bit.
  

This is a very fair concern; and one that is a risk for me on the uDig side - given that uDig is taking trunk seriously I expect to turn up lots of bug fixes around areas of the library that are "new" since GeoTools 2.2 (so raster support; filter and the feature model) and there are known problems with referencing.

Can I ask where in the GeoSever code base the system properties to control the referening module are? I have tried figuring out what to set based on reading javadocs and have come up frustrated.

I've asked on the gt2 channel about what will the 2.6.0 major change be, hopefully that will shed some light on this last concern.
  

I am also waiting on that thread; currently my vote is a range of -1..1 inclusive...
Jody

3

Having lived through the debate not that long ago, I dont yet see a
compelling reason to change our conclusions: GeoServer trunk should
always follow GeoTools trunk, and any fixes to branches should be
ported forward to trunk. If we need a stable baseline badly enough,
then a new bracnh (gt 2.6) and there is an overhead for client
applications to branch to match it, and keep both trunks alive and up
to date as the core investment.

I realise this is easier said than done, and am facing the challenges
of porting forward stuff fixed on 2.4 modules to trunk, and deciding
whether to skip 2.5, 2.6 etc, but I think it will be broken without
hope if the trunks arent the main focus of effort and driving each
other.

2c, (1c in Europe :slight_smile: )
Rob A

On Thu, Jul 31, 2008 at 8:06 AM, Jody Garnett <jgarnett@anonymised.com> wrote:

Andrea I am starting up a major (and short term) project on uDig trunk -
with a deadline in October. So I cannot afford to have geotools trunk go
crazy either. Jesse also wants to demo uDig trunk at FOSS4G which I
think agrees with the GeoServer 2.0 timeline?

So, what will it be? PSC, we need a decision.

So as a GeoServer PSC the question for me comes down to exactly what the
scope is for 2.6.0 - if it is just a race to get the wicket UI ready in
time for demo at FOSS4G in september I am going to be tempted to
recommend staying with GeoTools 2.5.0 (yes I understand that this is a
bad long term risk management move; and I also understand it would
really hurt my above mentioned uDig project).

All things considered, having gt2 trunk go wild scares me more than having to deal with the occasional issues due to living on trunk but the ability to release 2.6.0 in time concerns me quite a bit.

This is a very fair concern; and one that is a risk for me on the uDig
side - given that uDig is taking trunk seriously I expect to turn up
lots of bug fixes around areas of the library that are "new" since
GeoTools 2.2 (so raster support; filter and the feature model) and there
are known problems with referencing.

Can I ask where in the GeoSever code base the system properties to
control the referening module are? I have tried figuring out what to set
based on reading javadocs and have come up frustrated.

I've asked on the gt2 channel about what will the 2.6.0 major change be, hopefully that will shed some light on this last concern.

I am also waiting on that thread; currently my vote is a range of -1..1
inclusive...
Jody

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel