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