On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote:
> Luciano Resende wrote: > > > I was waiting to start this discussion after SCA 1.2 was out of the > > door, but looks like you were faster then me. I'm +1 on this, and here > > is my proposal. > > > > - Continue with SCA 1.x maintenance releases based on the current SCA > > 1.2 branch. This would be a more stable codebase, and we should avoid > > big changes that could brake backward compatibility here. > > > > - Use trunk as our SCA 2.0 release stream, where we would do the type > > of work discussed in [1], the cleanup and restructuring mentioned by > > you on this thread, as well as any other work that the community feels > > its applicable. > > > > Note that my proposal does not exclude merging items between branch > > and trunk as necessary, but this would probably be done case by case > > when the community thinks it's applicable. > > > > Thoughts ? > > > > > > [1] > > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html > > > > On Tue, Apr 8, 2008 at 12:55 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > > > With 1.2 almost out the door how about starting to think about our > > > next > > > release... > > > > > > We've had several discussions in the past about restructuring and > > > cleaning > > > up the distributions, build, and SPIs etc, is this the time to do > > > that? > > > Looking about the code there's many things that could be tidied up > > > but we've > > > been leaving them to keep backward compatibility, if we start this > > > type of > > > thing now it will make the next release not backward compatible so we > > > need > > > to agree this is the right time. We could make a new 1.x branch to > > > use as a > > > maintenance branch for the previous releases so we can still get > > > fixes out > > > for them. > > > > > > Leaving aside for now any detail about what the clean up and breaking > > > changes might be what do you all think about doing this in the next > > > release? > > > I think its the right time so am in favour of starting this. > > > > > > ...ant > > > > > > > > > I think it's time to restart that discussion. > > I was busy with conferences the last two weeks and had less time to keep > up with the dev discussions. Now that I'm catching up with email it is > becoming very apparent to me that there are a number of good discussions and > initiatives that can lead to good changes and improvements of our code base. > > Here are a few examples, in no particular order: > > - Databinding work, with some brainstorming started by Raymond. > > - OSGi integration, which may lead to SPI and module changes, maybe even > some distribution changes. > > - Extension mechanism, with some discussions about switching to XML and/or > using definitions.xml or similar mechanisms. > > - SCA domain implementation, I'm starting to see emerge different trends / > directions, not addressed by the recent work that Simon and I have done in > that area. > > - Runtime integration in particular with Web containers. I think that We > now have 3 or 4 different variants of this. > > - Model changes, in particular in the area of Bindings/Endpoints, which > will lead to Provider SPI changes too. > > - Changes to our WSDL modeling story, Java2WSDL generation, and looking at > the difficulties Mike went through in the BPEL integration to get his hands > on WSDL, I think we can improve that WSDL model and handling too. > > - New SCA client APIs (still need to catch up with that but it looks like > there's good discussions about that too). > > - Support for the SCA/JEE spec, which I think will bring new requirements > to our models and SPIs. > > I'm probably missing a few more items like that, but the point is that we > need a place to work on all these new ideas. > > On the other hand, I think it's really important to continue to maintain > the code base that works today alive with it's APIs and SPIs, for all the > people who currently use, integrate and embed Tuscany, and to be able to > continue to promote SOA and the SCA programming model with that code base. > > So, how about starting a 2.0 branch for the new stuff that we want to > rework, and a 1.x branch for the existing code base? > > Here's my +1 :) > > -- > Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym
