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 structure is - only that they are putting their
> active developent on trunk and that they have a build working against
> trunk to help with stability - aka don't offload instability onto the
> geotools project without providing some safety checks.
>> 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
>> functionality requirements? Perhaps think what Andrea would say about
>> stability before suggesting that gs-trunk would work well on gt-trunk
>> (without re-thinking how gt-trunk is currently a big old R&D experiment)
> geotools/trunk - latest produces milestones 2.4.0-M0
> geoserver/trunk - latest produces milestones 1.6.0-M0
> udig/trunk - latest produces milestones 1.2.0-M0
>
> geotools/branches/2.3.x - produces point releases 2.3.1, 2.3.2 ...
> geoserver/branches/1.5.x - produces point releases 1.5.0, 1.5.1, 1.5.2 ...
> udig/branches/1.1.x - produces point releases 1.1.1, 1.1.2 etc...
I too feel we cannot have more than 3 active branches at a time because
of obvious bug fixing pain. At the moment if you do a fix that involves
both geotools and geoserver theoretically you should:
* fix gt 2.2.x, port onto 2.3.x (easy) and on 2.4.x (harder because of
the different directory structure)
* fix gs 1.4.x, port onto 1.5.x (easy) and on ows4 (harder because
classes are different, so patches must be hand applied)
So I guess Geotools should follow the same rules as Geoserver when it
comes to branches, with not two but three different focuses:
* stable (2.2.x): only bug fixing, no fancy changes.
* latest (2.3.x): accept new modules and minor API changes.
Only low risk changes accepted on the modules provided that a positive
PMC vote allows them (think for example connection pooling on jdbc
datastores)
* experimental (trunk): free for API experimentation, but with some
necessary synch and care, so that trunk never becomes non working
forcing major apps (Geoserver, uDig) to abandon it.
I think the following shall be required:
* major changes and additions shall be approved by PMC
* the number of major changes shall be controlled, no two concurrent
major changes on the same subsystem should be allowed in order
to avoid conflicts and bad build breackages
* no last minute big changes, trunk must periodically settle down
and become latest
This cycle shall not be too long, otherwise trunk becomes too distant
from latest (think about poor users trying to upgrade), and at the
same time not too frequent, because it would make stable branches
live too short.
A cycle of 3/6 months seems a reasonable compromise to me. Its actual
duration shall be determined on a case by case basis I guess, since
paid work fuels quite a bit of the current geotools evolution and we
cannot risk to piss off customers.
What do you think?
Cheers
Andrea
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
