Moving this discussion to Geotools ...
What do you want to see in 2.1 and in 2.2?
I don't know what people think, but my feeling is that 2.1 has been released and so all new functionalities should go on 2.2. Also don't know if 2.2 API is going to change in a way that creates too many incompatibilities with 2.1 that people prefer to have a stable 2.1 branch for a while. It seems to be Jody's thinking at least and he has very good reasons.
By the other hand we're going to have a deep inspection of the featuretype api and, though I don't think it will end up with huge changes, I do think this should be done on 2.2.
So far the minimal change I can make to FeatureType to have it work is to add a:
public AttributeType Feature.getAttributeTypes() method
(With the understanding that the AttributeTypes are in the same order as the values).
That will get us consistency, but it is a lot of email and IRC to explain why. The other change would be to treat the FeatureType and Feature as pure data. And leave the XPath query (done by Filter PropertyName element) to be implemented by JXPath. This would mean most modules would interact with Feature data by way of Filter and Expression - which is a *very* smart move. If styling and rendering always interacts via Expression then we can set up that subsystem to work on XML for example.
But I am starting to get off topic ...
I would say to let 2.2 on trunk and develop _any_ new thing on it, and do just bug fixes on 2.1, whether they come from a fix on 2.1 itself or a backport from trunk.
That is my understanding as well. I also would not cry if you need to backport additive plugins, some things
did not make the cut for Geotools 2.1.0 (like hsql datastore).
Jody mentions having a stable release process, something like realeasing every six months, but I'm concerned that we'll be able to manage such a discipline, and not get stuck in large integration processes between branches.
May be I would try somehing like Chris' idea of making a point release on a release early-release often basis, and I understand that such a strategy would require a lot more of day-to-day involvement from those of us that are more intermittently showing up, at least to maintain our modules up to date...
I am happy with either approach - I will point out that Cholmes idea of releasing when someone commits to
merging in a new feature is was dependent on the person doing the merge putting in the work to update all
the modules. This policy would increase platform stability, but the overhead of big changes may be so big that
the library would never improve.
Users may be happy with a steady release policy - it is a total tradeoff. What do you think would be the most benefit?
ok, I know I'm going around in circles... I would prefer 2.1 freeze and 2.2 on trunk holding the load of new functionality, and GeoServer 1.4.x on 2.2.x
do you think it's too risky for the stability of Geoserver and uDig?
If so, would you preffer doing complex features support on 2.1.x?
I think Geotools PMC needs to do the leadership thing. Once uDig and GeoServer know what is going to happen
we can plan accordingly.
Jody
