You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2008/05/13 09:26:53 UTC
Re: SCA 2.0, was Re: Next SCA release
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 <an...@gmail.com> 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
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>> I was thinking about a branch to make it clear that it was shared and that
>> this work was open to all, but I'm also happy to see that work start in
>> shared sandboxes.
>
> I guess from whats been said so far then I'd favour using sandboxes
> for now for specific work that really can't be done in trunk, and
> where ever possible continue to use trunk to do what can be done there
> (looking at that list of examples i think we could find ways to do a
> lot in trunk).
>
I also think that many of these could be done in trunk. It would
be good to talk about each of these and come to a conclusion on
what the options are for a solution, and whether or not these
proposed options can be implemented in trunk.
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
> I was thinking about a branch to make it clear that it was shared and that
> this work was open to all, but I'm also happy to see that work start in
> shared sandboxes.
I guess from whats been said so far then I'd favour using sandboxes
for now for specific work that really can't be done in trunk, and
where ever possible continue to use trunk to do what can be done there
(looking at that list of examples i think we could find ways to do a
lot in trunk).
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
>>>> jsdelfino@apache.org> wrote:
>>>> I prefer a branch to make it clear that all in the community can work
>>>>> in
>>>>> it, to make it clear that it's accepted by the project, that it's
>>>>> buildable
>>>>> etc, instead of having work buried in the middle of a sandbox
>> together
>>>>> with
>>>>> obsolete or broken stuff, with an unclear status.
>>>>>
>>>> simonslaws@googlemail.com wrote:
>>>> So you mean a branch for 2.0 (you did say this in your previous post
>> and
>>>> my
>>>> eyes skipped over it) and trunk would remain as 1.x ?
>>>>
>>> jsdelfino@apache.org> wrote:
>>> It doesn't really make a difference for me: just 2 folders, one for 1.x
>>> one for 2.0, and just make clear which one is which and what's its
>> purpose.
>>> I'm fine with whatever option people prefer: trunk for 2.0 and
>>> branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0,
>> sandbox/2.0,
>>> whatever keeps our community happy.
>>>
>> simonslaws@googlemail.com wrote:
>> Given the amount of activity we have going on in trunk at the moment, I
>> would support 1.x remaining as trunk and cutting a branch to allow for
>> more
>> innovative (read breaking) development in a 2.0 code stream.
>>
+1 that makes sense to me
> ant elder wrote:
> It sounds like I (and a lot of the other committers) are going to be quite
> busy developing the current trunk for the next couple of months and that
> will make it difficult to participate fully in what happens in a parallel
> branch. Can this new work really not happen in trunk? Whats changed to make
> all the comments at the bottom of [1] no longer relevant?
>
> ...ant
>
> [1] http://apache.markmail.org/message/7ksuvizroitpafnp
>
What's changed is the design discussions that have recently popped up on
the list (I gave 9 examples) [2], which IMO will require concrete work
including breaking changes, and I think we need a place for that kind of
work to happen without breaking the stability of the current code base
in trunk.
The earlier email you referenced [1] also said this:
====
Many of the items suggested for 2.0 have previously been the subject of
discussions that have not been easy to close. Until we have agreement on
how to approach these things, I think it's better for 2.0 development to
happen in an "investigative" branch. Doing this will allow us to try
different approaches and see which we prefer, without causing a lot of
churn to the trunk.
====
That's consistent with my view, and I'm looking for the right Subversion
folder to make progress on the 9 mentioned items, hoping that it'll help
the community discuss and reach consensus based on concrete work / code.
I was thinking about a branch to make it clear that it was shared and
that this work was open to all, but I'm also happy to see that work
start in shared sandboxes. On a related note, it looks like this is what
Adriano and Oscar are doing with the Android port for example.
[2] http://marc.info/?l=tuscany-dev&m=121066365312526
Thoughts?
--
Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Wed, May 14, 2008 at 11:01 AM, Simon Laws <si...@googlemail.com>
wrote:
> On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> > Simon Laws wrote:
> >
> > > snip....
> > >
> > >
> > > I prefer a branch to make it clear that all in the community can work
> > > > in
> > > > it, to make it clear that it's accepted by the project, that it's
> > > > buildable
> > > > etc, instead of having work buried in the middle of a sandbox
> together
> > > > with
> > > > obsolete or broken stuff, with an unclear status.
> > > >
> > > >
> > > So you mean a branch for 2.0 (you did say this in your previous post
> and
> > > my
> > > eyes skipped over it) and trunk would remain as 1.x ?
> > >
> > > Simon
> > >
> > >
> > It doesn't really make a difference for me: just 2 folders, one for 1.x
> > one for 2.0, and just make clear which one is which and what's its
> purpose.
> >
> > I'm fine with whatever option people prefer: trunk for 2.0 and
> > branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0,
> sandbox/2.0,
> > whatever keeps our community happy.
> >
> > --
> > Jean-Sebastien
> >
>
> Given the amount of activity we have going on in trunk at the moment, I
> would support 1.x remaining as trunk and cutting a branch to allow for
> more
> innovative (read breaking) development in a 2.0 code stream.
>
> Simon
>
It sounds like I (and a lot of the other committers) are going to be quite
busy developing the current trunk for the next couple of months and that
will make it difficult to participate fully in what happens in a parallel
branch. Can this new work really not happen in trunk? Whats changed to make
all the comments at the bottom of [1] no longer relevant?
...ant
[1] http://apache.markmail.org/message/7ksuvizroitpafnp
Re: SCA 2.0, was Re: Next SCA release
Posted by Venkata Krishnan <fo...@gmail.com>.
+1 to Simon's view point. I also see this good from one of our earlier
objective to keep our trunk stable. I'd prefer that we evolve the
(potentially breaking) changes that we want to do in our road to 2.0
initially in a branch.
Just a worry - would it be challenging to keep the branch and trunk in sync
from a feature enhancements perspective. i.e. if there are some feature
enhancements that go into the trunk then we have to ensure that equivalent
ones go into the branch smoothly riding over the changes that have happened
in there.
- Venkat
On Wed, May 14, 2008 at 3:31 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> > Simon Laws wrote:
> >
> > > snip....
> > >
> > >
> > > I prefer a branch to make it clear that all in the community can work
> > > > in
> > > > it, to make it clear that it's accepted by the project, that it's
> > > > buildable
> > > > etc, instead of having work buried in the middle of a sandbox
> together
> > > > with
> > > > obsolete or broken stuff, with an unclear status.
> > > >
> > > >
> > > So you mean a branch for 2.0 (you did say this in your previous post
> and
> > > my
> > > eyes skipped over it) and trunk would remain as 1.x ?
> > >
> > > Simon
> > >
> > >
> > It doesn't really make a difference for me: just 2 folders, one for 1.x
> > one for 2.0, and just make clear which one is which and what's its
> purpose.
> >
> > I'm fine with whatever option people prefer: trunk for 2.0 and
> > branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0,
> > whatever keeps our community happy.
> >
> > --
> > Jean-Sebastien
> >
>
> Given the amount of activity we have going on in trunk at the moment, I
> would support 1.x remaining as trunk and cutting a branch to allow for more
> innovative (read breaking) development in a 2.0 code stream.
>
> Simon
>
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Tue, May 13, 2008 at 7:02 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> Simon Laws wrote:
>
> > snip....
> >
> >
> > I prefer a branch to make it clear that all in the community can work
> > > in
> > > it, to make it clear that it's accepted by the project, that it's
> > > buildable
> > > etc, instead of having work buried in the middle of a sandbox together
> > > with
> > > obsolete or broken stuff, with an unclear status.
> > >
> > >
> > So you mean a branch for 2.0 (you did say this in your previous post and
> > my
> > eyes skipped over it) and trunk would remain as 1.x ?
> >
> > Simon
> >
> >
> It doesn't really make a difference for me: just 2 folders, one for 1.x
> one for 2.0, and just make clear which one is which and what's its purpose.
>
> I'm fine with whatever option people prefer: trunk for 2.0 and
> branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0, sandbox/2.0,
> whatever keeps our community happy.
>
> --
> Jean-Sebastien
>
Given the amount of activity we have going on in trunk at the moment, I
would support 1.x remaining as trunk and cutting a branch to allow for more
innovative (read breaking) development in a 2.0 code stream.
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> snip....
>
>
>> I prefer a branch to make it clear that all in the community can work in
>> it, to make it clear that it's accepted by the project, that it's buildable
>> etc, instead of having work buried in the middle of a sandbox together with
>> obsolete or broken stuff, with an unclear status.
>>
>
> So you mean a branch for 2.0 (you did say this in your previous post and my
> eyes skipped over it) and trunk would remain as 1.x ?
>
> Simon
>
It doesn't really make a difference for me: just 2 folders, one for 1.x
one for 2.0, and just make clear which one is which and what's its purpose.
I'm fine with whatever option people prefer: trunk for 2.0 and
branches/1.x or trunk for 1.x and branches/2.0, or foo/2.0,
sandbox/2.0, whatever keeps our community happy.
--
Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
snip....
> I prefer a branch to make it clear that all in the community can work in
> it, to make it clear that it's accepted by the project, that it's buildable
> etc, instead of having work buried in the middle of a sandbox together with
> obsolete or broken stuff, with an unclear status.
>
So you mean a branch for 2.0 (you did say this in your previous post and my
eyes skipped over it) and trunk would remain as 1.x ?
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Nash wrote:
> ant elder wrote:
>> On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino <
>> jsdelfino@apache.org> 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 <an...@gmail.com> 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
>>
> I don't think we should be putting 1.x into maintenance mode now.
I agree. In my initial email I said 'maintain ... live'. By 'live' I
meant that non-breaking changes, evolutions, improvements would still go
into 1.x to support our user community and the efforts to help increase
adoption of SCA based on that code (tutorials, samples, various
integrations with other projects, a stable base for newcomers to get on
board the project, etc).
>
> I'm open to having an exploratory branch for 2.0 that would be used
> as a place to experiment with new ideas that can't be done in the 1.x
> trunk because they are too disruptive.
Like most of the items currently being discussed, which I listed above.
If we want to tackle them well they have to be disruptive.
If we do this, we'll need to
> have a clear understanding of what things would be done in the 2.0
> branch and what activity would continue in 1.x. My view is that
> anything that doesn't require breakage would be done in 1.x for now.
+1, exactly
> Another approach could be to start by doing the experimental work in
> sandboxes.
>
I prefer a branch to make it clear that all in the community can work in
it, to make it clear that it's accepted by the project, that it's
buildable etc, instead of having work buried in the middle of a sandbox
together with obsolete or broken stuff, with an unclear status.
On the other hand, I think it doesn't really make much difference to
work in foo/some-work, bar/some-work, sandbox/some-work or
branches/some-work. More important for me is how many people work in
that folder, is that work open to all, and is the result of that work
available to the community.
> Simon
>
--
Jean-Sebastien
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
> On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> 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 <an...@gmail.com> 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
>
I don't think we should be putting 1.x into maintenance mode now.
I'm open to having an exploratory branch for 2.0 that would be used
as a place to experiment with new ideas that can't be done in the 1.x
trunk because they are too disruptive. If we do this, we'll need to
have a clear understanding of what things would be done in the 2.0
branch and what activity would continue in 1.x. My view is that
anything that doesn't require breakage would be done in 1.x for now.
Another approach could be to start by doing the experimental work in
sandboxes.
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> 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 <an...@gmail.com> 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