[Geoserver-devel] Geotools 2.2.x --> new stable branch?

GeoServer GeoServer Developer
1

I've been talking to several people about the 2.2.x branch and the 2.3
"trunk".

From what I've managed to gather, it appears that most of the big
changes are happening on branches and will be (very soon) merging in
trunk. These merge-ins will be the 2.3 release. Soon after that - I'm
sure - development for 2.4 will start. The consensus seems to be about
"6 months" before you can really "trust" 2.3. I am looking forward to
it coming together and being solid.

The 2.2.x branch was started a little while ago. There wasn't any real
fan-fare to it - the announcement was "I took the liberty of creating
the 2.2.x branch.". I was skeptical about its trustworthiness, but
after putting several people several people under the Bright White
Light, they all said that its "good." I know that myself (and others)
spent a lot of time moving all the 2.1.x fixes forward to trunk so they
would be in this release. Apparently, not much has happened on 2.2.x
(the old trunk) in the last few months except bug fixes. The people
using it seem to all think its good (if anyone disagrees - please speak
up).

I've also seen several people (including myself) concerned about API
shifts and lack of maintenance. So, why don't we setup a new stable
branch? Currently, the stable branch is 2.1.x. I'd like to see a
place where we can continue improvements where we're not getting our
toes stepped on. So, I'm proposing making 2.2.x the 'official' stable
branch.

I think this just requires getting an "official consensus", but I think
we just need to define what we mean by the 'official stable branch.'
Here's some ideas:

1. have a big "advertisement" on the geotools front page that announces
2.2.x as the 'official stable branch'
2. encourage (especially new) users to use the official stable branch
3. encourage users to report bugs against this version
4. encourage users to submit patches against this version
5. recommend people who need to make more substantive changes to use the
unstable (2.3) version and warn them of the implications.

This means the 'official stable branch' isn't something we create and
then immediately forget about - its 'supported'.

The most controversial points will be "what changes are allowed to take
place on the stable branch"? Obviously things like changing the
feature model isn't in scope for the stable branch, but I'd still like
to see people able to add/fix things.

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."

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.

What think?

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).

(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'.)

I'm quite worried that if geotools doesn't have a supported stable
branch that we're going to get ourselves in trouble. I also think that
having official stability will encourage new users, bug reports, bug
fixes, and documentation. We really need that!

Dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

dblasby@anonymised.com wrote:

I'm quite worried that if geotools doesn't have a supported stable
branch that we're going to get ourselves in trouble. I also think that
having official stability will encourage new users, bug reports, bug
fixes, and documentation. We really need that!
  

Indeed, and thanks for the encouragement Dave. I think everyone will be happier once we settle on a course
of action :wink: And please be patient with us, remember geotools is really only on its third real release here,
we are all learning and figuring it out as we go along.

Put another way:
- 2.0.0 showed a release was possible (after 6 years), it is too bad that a lot of volunteers were just helping out until this happened :wink: (yeah everyone!)
- 2.1.0 taught us how to do our first major API shift (CoordinateReferenceSystem) and how scary that was (and costly in terms of developer trust). And frankly my trust.
- 2.1.1 showed that a stable release was possible, one that was maintained (yeah Dave)
- 2.2.0 showed us a much better way of development where short term (two week branches) were merged in to create milestones resulting in a trunk that could be released at any point (yeah everyone)
- 2.3.M0 showed us how a major api shift could be done using the branch and merge idea (yeah Justin)
- 2.3.M1 is stretching everything to it limit as we revise the heart of geotools (hold on Justin)
- 2.4.x is going to show us if the long term branch idea will work (coverage will be out for over a year at that point!)

Cheers,
Jody

3

dblasby@anonymised.com wrote:

The 2.2.x branch was started a little while ago.

It was marked as trunk for the longest time, from my perspective it started the moment 2.1.0 was
released :wink:

So, I'm proposing making 2.2.x the 'official' stable branch.
  

That is the plan, we are waiting on a) someone to care (perhaps you) and/or b) udig 1.1 (when I will
be the person caring).

I think this just requires getting an "official consensus", but I think
we just need to define what we mean by the 'official stable branch.' Here's some ideas:

1. have a big "advertisement" on the geotools front page that announces
2.2.x as the 'official stable branch'
2. encourage (especially new) users to use the official stable branch
3. encourage users to report bugs against this version
4. encourage users to submit patches against this version
5. recommend people who need to make more substantive changes to use the
unstable (2.3) version and warn them of the implications.
  

One more:
6. Mark it stable aka 2.2.0 :slight_smile:

This means the 'official stable branch' isn't something we create and
then immediately forget about - its 'supported'.
  

Indeed the uDig 1.1 stable branch will based on this for at least 6 months to a year (aka what we
use to make money and feed ourselves).

The most controversial points will be "what changes are allowed to take
place on the stable branch"? Obviously things like changing the
feature model isn't in scope for the stable branch, but I'd still like
to see people able to add/fix things.
  

We do have stuff in our developers guide on this (working on a stable branch page) .. from memory:
API changes - no
Functionality improvements - no
Functionality corrections - yes (i.e. when were were wrong about a standard)
Additional Plug-ins - yes

Fun stuff,
Jody

4

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 :frowning:

Jody

5

dblasby@anonymised.com a écrit :

I think this just requires getting an "official consensus", but I think
we just need to define what we mean by the 'official stable branch.' Here's some ideas:

1. have a big "advertisement" on the geotools front page that announces
2.2.x as the 'official stable branch'
2. encourage (especially new) users to use the official stable branch
3. encourage users to report bugs against this version
4. encourage users to submit patches against this version
5. recommend people who need to make more substantive changes to use the
unstable (2.3) version and warn them of the implications.

I would like to add one more criteria. Currently, the 2.2 branch depends on GeoAPI 2.0 (the latest stable version). I would like that it stay like that. I mean, the 2.2 branch should not depends on any kind of "geoapi-pending-xxx" version. This condition would exclude current Feature work, since they depend on the ongoing work in the GeoAPI pending directory. The GeoAPI dependency should stay frozen to 2.0.

  Martin.

6

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 :frowning:

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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com

7

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 :wink: 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 :wink:

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