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
