On 04/12/2007, Bruce Snyder <[EMAIL PROTECTED]> wrote: > On Dec 4, 2007 3:19 PM, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > I've finished writing the wiki page wrt to the smx4 subtree at > > http://cwiki.apache.org/confluence/display/SMX4/SVN+repo > > > > Feedback welcome. > > Regarding the two choices for the SMX 4 SVN repo, I'm starting to ask > myself the same question I always do when something starts to become a > little more complex than it feels like it should be: Is there an > easier way? IOW, what's the easiest route to take here? IMO, it's > probably more straightforward to give each component it's own > branches/tags/trunk dir. We don't want to cram everything into a > single dir tree and hide the complexities of building in the POMs.
Releases are a major bit of work to complete (and a PITA :); so I'm a little nervous about having too many separate releases, trunks and different branches. So I'm wondering about trying to minimise releases into these parts... (i) parent, core bundles (for jaxb and stuff) and runtime (ii) nmr & jbi support (iii) components, tools and the full SMX distro Then (ii) depends on (i) and (iii) depends on (i) and (ii) (though a component may only depend on (i) I guess). In the early days I see (i) and (ii) releasing frequently, but (i) should become stable & not need many releases soon, as will (ii) some time after that and then eventually we'll mostly put our efforts into releasing (iii). Eventually the main reason for releasing (i) and (ii) will mostly be minor patches and changes to core dependencies like spring versions etc. Hopefully this split will help make releasing easier (less to build & test). We could always split things up or aggregate them together further down the line if we think it makes sense - but given the large amount of effort & documentation required for each release I'd rather us have slightly less released parts than too many. -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
