You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2008/04/08 18:27:25 UTC
SCA 2.0, was Re: Next SCA release
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
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 10, 2008 at 4:43 AM, Mark Combellack <mc...@apache.org> wrote:
>
> * Version 2.x will be the main focus
> * Most of the development effort happens on Version 2.x
> * We will make API changes which means that it will not be backwards
> compatible with version 1
> * Version 1.x will go into "maintenance mode".
> * May get some bug fixes and minor updates
>
> If my presumptions are correct then, from my point of view, we should keep
> the trunk as the most up to date version - i.e. Version 2.
>
> Any maintenance for previous Version 1.x release should be done on their own
> branches.
>
+1
I still think this is the way we should go. As I said in my original
proposal, I was expecting community members to have interest in keep
maintaining and adding small enhancements to the 1.x branch, we have
many users consuming releases from that branch, that might need bug
fixes, etc.
>
>
> ant also makes an interesting point about timing. Without clear goals and
> objectives for Version 2.x, perhaps we should hold off on branching.
>
We have spent a good amount of time to make sure the 1.2 branch is
very clean, and working perfectly for the release. With this said, I
think it should be considered to be the source for 1.x branch, and we
should consider cutting the branch at the moment we have 1.2 out of
the door.
> Mark
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Tue, Apr 15, 2008 at 8:29 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
<snip>
After a week away I thought we'd have a clearer picture on this. Yesterday I
> put together some improvements of the admin app and some of the tutorial
> modules. I must say I'm a little lost now as to where I should commit that
> stuff.
>
Thats easy - to trunk. Development happens in the trunk.
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> On Fri, Apr 11, 2008 at 3:28 AM, ant elder <an...@gmail.com> wrote:
>> On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash <na...@apache.org> wrote:
>>
>> <snip>
>>
>>
>> +1. 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.
>> >
>>
>> So based on the comments so far I think we should hold off on moving to 2.0
>> for now.
>
> +1, let's get consensus first.
>
>> That said I'm extremely wary of the having work going on in "investigative"
>> branches, given Tuscany's history of branches and forks I really really hope
>> this doesn't happen much and we'd instead all try to work together in the
>> trunk.
>>
>
> +1
>
>> ...ant
>>
>
After a week away I thought we'd have a clearer picture on this.
Yesterday I put together some improvements of the admin app and some of
the tutorial modules. I must say I'm a little lost now as to where I
should commit that stuff.
It's difficult to see where we are in this long thread. Is there a
consensus? Can somebody please summarize where we are?
Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi,
+1 for moving the trunk to 2.0 and working on all the changes that we have
been wanted to make to the SPIs, distribution packaging, runtimes etc.
+1 for having 1.2 as maintenance branch and keeping it stable. Any
improvements keeping this as base could continue on the branch and maybe if
our 2.0 release if going to take a while, we could make some 1.2.x sort of
minor releases. Since the branch has been cleaned up the release work for
these should hopefully be less too.
+1 for keeping the same space for the docs but create a separate stream of
docs for version 2 specific things. This is 'option 2' in the proposal
related to documentation.
Thanks
- Venkat
On Sat, Apr 12, 2008 at 5:34 AM, Luciano Resende <lu...@gmail.com>
wrote:
> On Fri, Apr 11, 2008 at 3:28 AM, ant elder <an...@gmail.com> wrote:
> > On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash <na...@apache.org> wrote:
> >
> > <snip>
> >
> >
> > +1. 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.
> > >
> >
> > So based on the comments so far I think we should hold off on moving to
> 2.0
> > for now.
>
> +1, let's get consensus first.
>
> >
> > That said I'm extremely wary of the having work going on in
> "investigative"
> > branches, given Tuscany's history of branches and forks I really really
> hope
> > this doesn't happen much and we'd instead all try to work together in
> the
> > trunk.
> >
>
> +1
>
> > ...ant
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: SCA 2.0, was Re: Next SCA release
Posted by Luciano Resende <lu...@gmail.com>.
On Fri, Apr 11, 2008 at 3:28 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash <na...@apache.org> wrote:
>
> <snip>
>
>
> +1. 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.
> >
>
> So based on the comments so far I think we should hold off on moving to 2.0
> for now.
+1, let's get consensus first.
>
> That said I'm extremely wary of the having work going on in "investigative"
> branches, given Tuscany's history of branches and forks I really really hope
> this doesn't happen much and we'd instead all try to work together in the
> trunk.
>
+1
> ...ant
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash <na...@apache.org> wrote:
<snip>
+1. 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.
>
So based on the comments so far I think we should hold off on moving to 2.0
for now.
That said I'm extremely wary of the having work going on in "investigative"
branches, given Tuscany's history of branches and forks I really really hope
this doesn't happen much and we'd instead all try to work together in the
trunk.
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
Comments inline.
Simon
Simon Laws wrote:
> On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack <mc...@apache.org>
> wrote:
>
>>> -----Original Message-----
>>> From: ant elder [mailto:ant.elder@gmail.com]
>>> Sent: 10 April 2008 12:26
>>> To: tuscany-dev@ws.apache.org
>>> Subject: Re: SCA 2.0, was Re: Next SCA release
>>>
>>> On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>> On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com>
>> wrote:
>>>>> On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
>>>>> jsdelfino@apache.org> wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>>> 1.3 sounds good to me. I'm assuming that we'll cut that branch out
>>> of
>>>>>> trunk?
>>>>>>
>>>>>> I'm asking because I'm interested in working on some improvements
>> of
>>>> 1.2
>>>>>> in the next few weeks. This shouldn't delay any 2.0 work however,
>>>> which
>>>>> can
>>>>>> go in parallel.
>>>>>>
>>>>>>
>>>>> That sounds scary.
>>>>>
>>>>> Are you saying you don't think its the right time for 2.0? I started
>>>> this
>>>>> discussion to see if there was consensus to move to 2.0, if there's
>>> not
>>>>> consensus then we should not do it. The last thing we need is dev
>>> going
>>>> on
>>>>> in multiple branches as happened in the old days.
>>>>>
>>>>> ...ant
>>>>>
>>>> Maybe this means we should consider the trunk to be 1.X and branch for
>>> 2.0
>>>> at the point at which someone wants to start investigating 2.0. I've
>>> been
>>>> thinking of this 2.0 exercise as investigative in the first instance
>>> hence
>>>> [1]. By that I mean that I would fully expect us to do other 1.X
>>> releases
>>>> before any 2.0 features appear in released form.
>>>>
This is my expectation as well.
>>>> B.t.w - have copied in the user list as we neglected to do this and
>> this
>>>> is
>>>> as much a user discussion as a developer discussion.
>>>>
>>>> Simon
>>>>
>>> Keeping maintenance branches going and porting fixes from trunk back to
>>> them
>>> seems fine but as has been demonstrated several times in Tuscany's
>> history
>>> we are not able to maintain a consensus based approach to development
>> when
>>> new development is going on in multiple branches. If we're not ready to
>>> make
>>> backward compatibility breaking changes to the trunk code then IMHO we
>>> should just wait.
>>>
>>> ...ant
>>
>> It all depends on the development focus. I am presuming that:
>>
>> * Version 2.x will be the main focus
>> * Most of the development effort happens on Version 2.x
>> * We will make API changes which means that it will not be backwards
>> compatible with version 1
>> * Version 1.x will go into "maintenance mode".
>> * May get some bug fixes and minor updates
>>
>> If my presumptions are correct then, from my point of view, we should keep
>> the trunk as the most up to date version - i.e. Version 2.
>>
>> Any maintenance for previous Version 1.x release should be done on their
>> own
>> branches.
>>
I don't think we are ready yet to "retire" the 1.x codebase to the
extent that's stated here. Like Sebastien, I plan to work on
improvements to the 1.x codebase over the next few weeks.
>>
>>
>> ant also makes an interesting point about timing. Without clear goals and
>> objectives for Version 2.x, perhaps we should hold off on branching.
>>
+1. 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.
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> Hi Mark
>
> I agree and specifically on your last point this was the basis of my comment
> about us being in the investigation stage, i.e. working out what our goals
> are. We definitely don't have a clear view of those at the moment other than
> the hazy things that we haven't yet clearly articulated. I don't have any
> feeling that we are in the position to jump into V2.0 development with a
> view to doing a release any time soon.
>
+1.
> I would also like to hear some user input on the things that are really
> important and whether they fall into the category of V2.0 breaking changes
> or V1.X compatible changes.
>
I think this is very important. I'd like to take the current 1.x
codebase as far as we can without making breaking changes, and
I don't think we have reached that point yet. When we have a list
of things that
1. we agree need doing, and how to do them
2. are based on user requirements
3. can't be done in 1.x
I think that would be the right time to switch the main project focus
over to the 2.0 codebase.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
Comments inline.
Simon
Simon Laws wrote:
> On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack <mc...@apache.org>
> wrote:
>
>>> -----Original Message-----
>>> From: ant elder [mailto:ant.elder@gmail.com]
>>> Sent: 10 April 2008 12:26
>>> To: tuscany-dev@ws.apache.org
>>> Subject: Re: SCA 2.0, was Re: Next SCA release
>>>
>>> On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>>
>>>> On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com>
>> wrote:
>>>>> On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
>>>>> jsdelfino@apache.org> wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>>> 1.3 sounds good to me. I'm assuming that we'll cut that branch out
>>> of
>>>>>> trunk?
>>>>>>
>>>>>> I'm asking because I'm interested in working on some improvements
>> of
>>>> 1.2
>>>>>> in the next few weeks. This shouldn't delay any 2.0 work however,
>>>> which
>>>>> can
>>>>>> go in parallel.
>>>>>>
>>>>>>
>>>>> That sounds scary.
>>>>>
>>>>> Are you saying you don't think its the right time for 2.0? I started
>>>> this
>>>>> discussion to see if there was consensus to move to 2.0, if there's
>>> not
>>>>> consensus then we should not do it. The last thing we need is dev
>>> going
>>>> on
>>>>> in multiple branches as happened in the old days.
>>>>>
>>>>> ...ant
>>>>>
>>>> Maybe this means we should consider the trunk to be 1.X and branch for
>>> 2.0
>>>> at the point at which someone wants to start investigating 2.0. I've
>>> been
>>>> thinking of this 2.0 exercise as investigative in the first instance
>>> hence
>>>> [1]. By that I mean that I would fully expect us to do other 1.X
>>> releases
>>>> before any 2.0 features appear in released form.
>>>>
This is my expectation as well.
>>>> B.t.w - have copied in the user list as we neglected to do this and
>> this
>>>> is
>>>> as much a user discussion as a developer discussion.
>>>>
>>>> Simon
>>>>
>>> Keeping maintenance branches going and porting fixes from trunk back to
>>> them
>>> seems fine but as has been demonstrated several times in Tuscany's
>> history
>>> we are not able to maintain a consensus based approach to development
>> when
>>> new development is going on in multiple branches. If we're not ready to
>>> make
>>> backward compatibility breaking changes to the trunk code then IMHO we
>>> should just wait.
>>>
>>> ...ant
>>
>> It all depends on the development focus. I am presuming that:
>>
>> * Version 2.x will be the main focus
>> * Most of the development effort happens on Version 2.x
>> * We will make API changes which means that it will not be backwards
>> compatible with version 1
>> * Version 1.x will go into "maintenance mode".
>> * May get some bug fixes and minor updates
>>
>> If my presumptions are correct then, from my point of view, we should keep
>> the trunk as the most up to date version - i.e. Version 2.
>>
>> Any maintenance for previous Version 1.x release should be done on their
>> own
>> branches.
>>
I don't think we are ready yet to "retire" the 1.x codebase to the
extent that's stated here. Like Sebastien, I plan to work on
improvements to the 1.x codebase over the next few weeks.
>>
>>
>> ant also makes an interesting point about timing. Without clear goals and
>> objectives for Version 2.x, perhaps we should hold off on branching.
>>
+1. 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.
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
> Hi Mark
>
> I agree and specifically on your last point this was the basis of my comment
> about us being in the investigation stage, i.e. working out what our goals
> are. We definitely don't have a clear view of those at the moment other than
> the hazy things that we haven't yet clearly articulated. I don't have any
> feeling that we are in the position to jump into V2.0 development with a
> view to doing a release any time soon.
>
+1.
> I would also like to hear some user input on the things that are really
> important and whether they fall into the category of V2.0 breaking changes
> or V1.X compatible changes.
>
I think this is very important. I'd like to take the current 1.x
codebase as far as we can without making breaking changes, and
I don't think we have reached that point yet. When we have a list
of things that
1. we agree need doing, and how to do them
2. are based on user requirements
3. can't be done in 1.x
I think that would be the right time to switch the main project focus
over to the 2.0 codebase.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack <mc...@apache.org>
wrote:
> > -----Original Message-----
> > From: ant elder [mailto:ant.elder@gmail.com]
> > Sent: 10 April 2008 12:26
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: SCA 2.0, was Re: Next SCA release
> >
> > On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com>
> wrote:
> > >
> > > > On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> > > > jsdelfino@apache.org> wrote:
> > > >
> > > > <snip>
> > > >
> > > >
> > > > > 1.3 sounds good to me. I'm assuming that we'll cut that branch out
> > of
> > > > > trunk?
> > > > >
> > > > > I'm asking because I'm interested in working on some improvements
> of
> > > 1.2
> > > > > in the next few weeks. This shouldn't delay any 2.0 work however,
> > > which
> > > > can
> > > > > go in parallel.
> > > > >
> > > > >
> > > > That sounds scary.
> > > >
> > > > Are you saying you don't think its the right time for 2.0? I started
> > > this
> > > > discussion to see if there was consensus to move to 2.0, if there's
> > not
> > > > consensus then we should not do it. The last thing we need is dev
> > going
> > > on
> > > > in multiple branches as happened in the old days.
> > > >
> > > > ...ant
> > > >
> > >
> > > Maybe this means we should consider the trunk to be 1.X and branch for
> > 2.0
> > > at the point at which someone wants to start investigating 2.0. I've
> > been
> > > thinking of this 2.0 exercise as investigative in the first instance
> > hence
> > > [1]. By that I mean that I would fully expect us to do other 1.X
> > releases
> > > before any 2.0 features appear in released form.
> > >
> > > B.t.w - have copied in the user list as we neglected to do this and
> this
> > > is
> > > as much a user discussion as a developer discussion.
> > >
> > > Simon
> > >
> >
> > Keeping maintenance branches going and porting fixes from trunk back to
> > them
> > seems fine but as has been demonstrated several times in Tuscany's
> history
> > we are not able to maintain a consensus based approach to development
> when
> > new development is going on in multiple branches. If we're not ready to
> > make
> > backward compatibility breaking changes to the trunk code then IMHO we
> > should just wait.
> >
> > ...ant
>
>
> It all depends on the development focus. I am presuming that:
>
> * Version 2.x will be the main focus
> * Most of the development effort happens on Version 2.x
> * We will make API changes which means that it will not be backwards
> compatible with version 1
> * Version 1.x will go into "maintenance mode".
> * May get some bug fixes and minor updates
>
> If my presumptions are correct then, from my point of view, we should keep
> the trunk as the most up to date version - i.e. Version 2.
>
> Any maintenance for previous Version 1.x release should be done on their
> own
> branches.
>
>
>
> ant also makes an interesting point about timing. Without clear goals and
> objectives for Version 2.x, perhaps we should hold off on branching.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi Mark
I agree and specifically on your last point this was the basis of my comment
about us being in the investigation stage, i.e. working out what our goals
are. We definitely don't have a clear view of those at the moment other than
the hazy things that we haven't yet clearly articulated. I don't have any
feeling that we are in the position to jump into V2.0 development with a
view to doing a release any time soon.
I would also like to hear some user input on the things that are really
important and whether they fall into the category of V2.0 breaking changes
or V1.X compatible changes.
Regards
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack <mc...@apache.org>
wrote:
> > -----Original Message-----
> > From: ant elder [mailto:ant.elder@gmail.com]
> > Sent: 10 April 2008 12:26
> > To: tuscany-dev@ws.apache.org
> > Subject: Re: SCA 2.0, was Re: Next SCA release
> >
> > On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com>
> wrote:
> > >
> > > > On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> > > > jsdelfino@apache.org> wrote:
> > > >
> > > > <snip>
> > > >
> > > >
> > > > > 1.3 sounds good to me. I'm assuming that we'll cut that branch out
> > of
> > > > > trunk?
> > > > >
> > > > > I'm asking because I'm interested in working on some improvements
> of
> > > 1.2
> > > > > in the next few weeks. This shouldn't delay any 2.0 work however,
> > > which
> > > > can
> > > > > go in parallel.
> > > > >
> > > > >
> > > > That sounds scary.
> > > >
> > > > Are you saying you don't think its the right time for 2.0? I started
> > > this
> > > > discussion to see if there was consensus to move to 2.0, if there's
> > not
> > > > consensus then we should not do it. The last thing we need is dev
> > going
> > > on
> > > > in multiple branches as happened in the old days.
> > > >
> > > > ...ant
> > > >
> > >
> > > Maybe this means we should consider the trunk to be 1.X and branch for
> > 2.0
> > > at the point at which someone wants to start investigating 2.0. I've
> > been
> > > thinking of this 2.0 exercise as investigative in the first instance
> > hence
> > > [1]. By that I mean that I would fully expect us to do other 1.X
> > releases
> > > before any 2.0 features appear in released form.
> > >
> > > B.t.w - have copied in the user list as we neglected to do this and
> this
> > > is
> > > as much a user discussion as a developer discussion.
> > >
> > > Simon
> > >
> >
> > Keeping maintenance branches going and porting fixes from trunk back to
> > them
> > seems fine but as has been demonstrated several times in Tuscany's
> history
> > we are not able to maintain a consensus based approach to development
> when
> > new development is going on in multiple branches. If we're not ready to
> > make
> > backward compatibility breaking changes to the trunk code then IMHO we
> > should just wait.
> >
> > ...ant
>
>
> It all depends on the development focus. I am presuming that:
>
> * Version 2.x will be the main focus
> * Most of the development effort happens on Version 2.x
> * We will make API changes which means that it will not be backwards
> compatible with version 1
> * Version 1.x will go into "maintenance mode".
> * May get some bug fixes and minor updates
>
> If my presumptions are correct then, from my point of view, we should keep
> the trunk as the most up to date version - i.e. Version 2.
>
> Any maintenance for previous Version 1.x release should be done on their
> own
> branches.
>
>
>
> ant also makes an interesting point about timing. Without clear goals and
> objectives for Version 2.x, perhaps we should hold off on branching.
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Hi Mark
I agree and specifically on your last point this was the basis of my comment
about us being in the investigation stage, i.e. working out what our goals
are. We definitely don't have a clear view of those at the moment other than
the hazy things that we haven't yet clearly articulated. I don't have any
feeling that we are in the position to jump into V2.0 development with a
view to doing a release any time soon.
I would also like to hear some user input on the things that are really
important and whether they fall into the category of V2.0 breaking changes
or V1.X compatible changes.
Regards
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 10, 2008 at 4:43 AM, Mark Combellack <mc...@apache.org> wrote:
>
> * Version 2.x will be the main focus
> * Most of the development effort happens on Version 2.x
> * We will make API changes which means that it will not be backwards
> compatible with version 1
> * Version 1.x will go into "maintenance mode".
> * May get some bug fixes and minor updates
>
> If my presumptions are correct then, from my point of view, we should keep
> the trunk as the most up to date version - i.e. Version 2.
>
> Any maintenance for previous Version 1.x release should be done on their own
> branches.
>
+1
I still think this is the way we should go. As I said in my original
proposal, I was expecting community members to have interest in keep
maintaining and adding small enhancements to the 1.x branch, we have
many users consuming releases from that branch, that might need bug
fixes, etc.
>
>
> ant also makes an interesting point about timing. Without clear goals and
> objectives for Version 2.x, perhaps we should hold off on branching.
>
We have spent a good amount of time to make sure the 1.2 branch is
very clean, and working perfectly for the release. With this said, I
think it should be considered to be the source for 1.x branch, and we
should consider cutting the branch at the moment we have 1.2 out of
the door.
> Mark
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
RE: SCA 2.0, was Re: Next SCA release
Posted by Mark Combellack <mc...@apache.org>.
> -----Original Message-----
> From: ant elder [mailto:ant.elder@gmail.com]
> Sent: 10 April 2008 12:26
> To: tuscany-dev@ws.apache.org
> Subject: Re: SCA 2.0, was Re: Next SCA release
>
> On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com> wrote:
> >
> > > On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> > > jsdelfino@apache.org> wrote:
> > >
> > > <snip>
> > >
> > >
> > > > 1.3 sounds good to me. I'm assuming that we'll cut that branch out
> of
> > > > trunk?
> > > >
> > > > I'm asking because I'm interested in working on some improvements of
> > 1.2
> > > > in the next few weeks. This shouldn't delay any 2.0 work however,
> > which
> > > can
> > > > go in parallel.
> > > >
> > > >
> > > That sounds scary.
> > >
> > > Are you saying you don't think its the right time for 2.0? I started
> > this
> > > discussion to see if there was consensus to move to 2.0, if there's
> not
> > > consensus then we should not do it. The last thing we need is dev
> going
> > on
> > > in multiple branches as happened in the old days.
> > >
> > > ...ant
> > >
> >
> > Maybe this means we should consider the trunk to be 1.X and branch for
> 2.0
> > at the point at which someone wants to start investigating 2.0. I've
> been
> > thinking of this 2.0 exercise as investigative in the first instance
> hence
> > [1]. By that I mean that I would fully expect us to do other 1.X
> releases
> > before any 2.0 features appear in released form.
> >
> > B.t.w - have copied in the user list as we neglected to do this and this
> > is
> > as much a user discussion as a developer discussion.
> >
> > Simon
> >
>
> Keeping maintenance branches going and porting fixes from trunk back to
> them
> seems fine but as has been demonstrated several times in Tuscany's history
> we are not able to maintain a consensus based approach to development when
> new development is going on in multiple branches. If we're not ready to
> make
> backward compatibility breaking changes to the trunk code then IMHO we
> should just wait.
>
> ...ant
It all depends on the development focus. I am presuming that:
* Version 2.x will be the main focus
* Most of the development effort happens on Version 2.x
* We will make API changes which means that it will not be backwards
compatible with version 1
* Version 1.x will go into "maintenance mode".
* May get some bug fixes and minor updates
If my presumptions are correct then, from my point of view, we should keep
the trunk as the most up to date version - i.e. Version 2.
Any maintenance for previous Version 1.x release should be done on their own
branches.
ant also makes an interesting point about timing. Without clear goals and
objectives for Version 2.x, perhaps we should hold off on branching.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com> wrote:
>
> > On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> > <snip>
> >
> >
> > > 1.3 sounds good to me. I'm assuming that we'll cut that branch out of
> > > trunk?
> > >
> > > I'm asking because I'm interested in working on some improvements of
> 1.2
> > > in the next few weeks. This shouldn't delay any 2.0 work however,
> which
> > can
> > > go in parallel.
> > >
> > >
> > That sounds scary.
> >
> > Are you saying you don't think its the right time for 2.0? I started
> this
> > discussion to see if there was consensus to move to 2.0, if there's not
> > consensus then we should not do it. The last thing we need is dev going
> on
> > in multiple branches as happened in the old days.
> >
> > ...ant
> >
>
> Maybe this means we should consider the trunk to be 1.X and branch for 2.0
> at the point at which someone wants to start investigating 2.0. I've been
> thinking of this 2.0 exercise as investigative in the first instance hence
> [1]. By that I mean that I would fully expect us to do other 1.X releases
> before any 2.0 features appear in released form.
>
> B.t.w - have copied in the user list as we neglected to do this and this
> is
> as much a user discussion as a developer discussion.
>
> Simon
>
Keeping maintenance branches going and porting fixes from trunk back to them
seems fine but as has been demonstrated several times in Tuscany's history
we are not able to maintain a consensus based approach to development when
new development is going on in multiple branches. If we're not ready to make
backward compatibility breaking changes to the trunk code then IMHO we
should just wait.
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com> wrote:
> On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> <snip>
>
>
> > 1.3 sounds good to me. I'm assuming that we'll cut that branch out of
> > trunk?
> >
> > I'm asking because I'm interested in working on some improvements of 1.2
> > in the next few weeks. This shouldn't delay any 2.0 work however, which
> can
> > go in parallel.
> >
> >
> That sounds scary.
>
> Are you saying you don't think its the right time for 2.0? I started this
> discussion to see if there was consensus to move to 2.0, if there's not
> consensus then we should not do it. The last thing we need is dev going on
> in multiple branches as happened in the old days.
>
> ...ant
>
Maybe this means we should consider the trunk to be 1.X and branch for 2.0
at the point at which someone wants to start investigating 2.0. I've been
thinking of this 2.0 exercise as investigative in the first instance hence
[1]. By that I mean that I would fully expect us to do other 1.X releases
before any 2.0 features appear in released form.
B.t.w - have copied in the user list as we neglected to do this and this is
as much a user discussion as a developer discussion.
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30237.html
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Apr 10, 2008 at 8:12 AM, ant elder <an...@gmail.com> wrote:
> On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> <snip>
>
>
> > 1.3 sounds good to me. I'm assuming that we'll cut that branch out of
> > trunk?
> >
> > I'm asking because I'm interested in working on some improvements of 1.2
> > in the next few weeks. This shouldn't delay any 2.0 work however, which
> can
> > go in parallel.
> >
> >
> That sounds scary.
>
> Are you saying you don't think its the right time for 2.0? I started this
> discussion to see if there was consensus to move to 2.0, if there's not
> consensus then we should not do it. The last thing we need is dev going on
> in multiple branches as happened in the old days.
>
> ...ant
>
Maybe this means we should consider the trunk to be 1.X and branch for 2.0
at the point at which someone wants to start investigating 2.0. I've been
thinking of this 2.0 exercise as investigative in the first instance hence
[1]. By that I mean that I would fully expect us to do other 1.X releases
before any 2.0 features appear in released form.
B.t.w - have copied in the user list as we neglected to do this and this is
as much a user discussion as a developer discussion.
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30237.html
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
> jsdelfino@apache.org> wrote:
>
> <snip>
>
>
>> 1.3 sounds good to me. I'm assuming that we'll cut that branch out of
>> trunk?
>>
>> I'm asking because I'm interested in working on some improvements of 1.2
>> in the next few weeks. This shouldn't delay any 2.0 work however, which can
>> go in parallel.
>>
>>
> That sounds scary.
>
> Are you saying you don't think its the right time for 2.0?
No, and I'm not sure about what's not clear in "I'm interested in
working on some improvements of 1.2 in the next few weeks. This
shouldn't delay any 2.0 work however, which can go in parallel." and why
it sounds scary.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
<snip>
> 1.3 sounds good to me. I'm assuming that we'll cut that branch out of
> trunk?
>
> I'm asking because I'm interested in working on some improvements of 1.2
> in the next few weeks. This shouldn't delay any 2.0 work however, which can
> go in parallel.
>
>
That sounds scary.
Are you saying you don't think its the right time for 2.0? I started this
discussion to see if there was consensus to move to 2.0, if there's not
consensus then we should not do it. The last thing we need is dev going on
in multiple branches as happened in the old days.
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> I'm +1 on this. Comments in line
>
> Simon.
>
>
>>> - 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.
>
> I propose that we create the branch for 1.x develop directly after 1.2 is
> out to make clear our intentions. It's not clear if the suggestion here is
> to create sca-java-1.X or sca-java-1.3. My vote would be for the latter
> (reserving sca-java-1.2.1 in case we need to address specific concerns in
> 1.2 that are not subject to ongoing maintenance activities).
>
1.3 sounds good to me. I'm assuming that we'll cut that branch out of trunk?
I'm asking because I'm interested in working on some improvements of 1.2
in the next few weeks. This shouldn't delay any 2.0 work however, which
can go in parallel.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
haleh mahbod wrote:
>> 1 - [] Put V2 doc changes in V1 pages and mark them as such
>> 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
> site wiki
>> 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
>
> Option 2 seems reasonable. Option 3 can be considered in the future if
> there is a need.
> It would be good to get user's perspective on all this.
>
+0.5 for options [1], [2] and maybe [3] later :)
I'm just saying 0.5 as looking at our current docs as I'm not sure about
how people are planning to change them in 2.0. It's a little difficult
to discuss a process to manage changes without knowing the extent and
nature of the changes :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-user-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-user-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
haleh mahbod wrote:
>> 1 - [] Put V2 doc changes in V1 pages and mark them as such
>> 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
> site wiki
>> 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
>
> Option 2 seems reasonable. Option 3 can be considered in the future if
> there is a need.
> It would be good to get user's perspective on all this.
>
+0.5 for options [1], [2] and maybe [3] later :)
I'm just saying 0.5 as looking at our current docs as I'm not sure about
how people are planning to change them in 2.0. It's a little difficult
to discuss a process to manage changes without knowing the extent and
nature of the changes :)
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by haleh mahbod <hm...@gmail.com>.
>1 - [] Put V2 doc changes in V1 pages and mark them as such
>2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
site wiki
>3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
Option 2 seems reasonable. Option 3 can be considered in the future if
there is a need.
It would be good to get user's perspective on all this.
On 4/9/08, Simon Laws <si...@googlemail.com> wrote:
>
> On Wed, Apr 9, 2008 at 5:03 PM, ant elder <an...@gmail.com> wrote:
>
> > On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <hm...@gmail.com>
> wrote:
> > >
> > > > +1 on versioning SCA docs
> > > >
> > > > Assuming two versions of SCA Java, I can see that the following page
> > > will
> > > > change to point to two different versions of SCA Java, 1.x and 2.x
> and
> > > > their
> > > > related documentation.
> > > >
> > > >
> > >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> > > >
> > > > Tuscany SCA Java general page would contain general information that
> > > would
> > > > pertain to both versions. So, it might need to change.
> > > > http://incubator.apache.org/tuscany/sca-java.html
> > > >
> > > > On the left navigation of sca-java page, we would have two boxes
> > > > SCA Java 2.x
> > > > SCA Java 1.x
> > > >
> > > > each would point to their own releases and their own documentations
> > and
> > > > source code tree.
> > > >
> > > > There is a set of documentations under SCA Java that are generic,
> like
> > > > development guide. We could share these pages between the two
> > versions.
> > > >
> > > > Does this make sense?
> > > >
> > > >
> > > Generally make sense to me.
> > >
> > > On the particular question of where to host V2 and V2 docs we have
> > > identified 3 choices so far.
> > >
> > > 1 - [] Put V2 doc changes in V1 pages and mark them as such
> > > 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> > > current
> > > site wiki
> > > 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
> > >
> > > Are there other cunning options we need to consider. I'm for option 2
> at
> > > the
> > > current time.
> > >
> > > Simon
> > >
> >
> > How would that option [2] actually work?
> >
> > Lets say I change the way the dwr binding works and want to update the
> doc
> > for V2, the current wiki page is at
> > http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what
> > would
> > i do for the new v2 page?
> >
> > ...ant
>
>
> You would make
> http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html<
> http://incubator.apache.org/tuscany/sca-java-bindingajax.html>.
> Copy the existing contents there. Edit them which whatever change you need
> to make and and then add a link to this page to the V2 index (which I
> expect
> will, by default, link to the existing pages).
>
> Simon
>
Re: SCA 2.0, was Re: Next SCA release
Posted by haleh mahbod <hm...@gmail.com>.
>1 - [] Put V2 doc changes in V1 pages and mark them as such
>2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
site wiki
>3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
Option 2 seems reasonable. Option 3 can be considered in the future if
there is a need.
It would be good to get user's perspective on all this.
On 4/9/08, Simon Laws <si...@googlemail.com> wrote:
>
> On Wed, Apr 9, 2008 at 5:03 PM, ant elder <an...@gmail.com> wrote:
>
> > On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > > On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <hm...@gmail.com>
> wrote:
> > >
> > > > +1 on versioning SCA docs
> > > >
> > > > Assuming two versions of SCA Java, I can see that the following page
> > > will
> > > > change to point to two different versions of SCA Java, 1.x and 2.x
> and
> > > > their
> > > > related documentation.
> > > >
> > > >
> > >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> > > >
> > > > Tuscany SCA Java general page would contain general information that
> > > would
> > > > pertain to both versions. So, it might need to change.
> > > > http://incubator.apache.org/tuscany/sca-java.html
> > > >
> > > > On the left navigation of sca-java page, we would have two boxes
> > > > SCA Java 2.x
> > > > SCA Java 1.x
> > > >
> > > > each would point to their own releases and their own documentations
> > and
> > > > source code tree.
> > > >
> > > > There is a set of documentations under SCA Java that are generic,
> like
> > > > development guide. We could share these pages between the two
> > versions.
> > > >
> > > > Does this make sense?
> > > >
> > > >
> > > Generally make sense to me.
> > >
> > > On the particular question of where to host V2 and V2 docs we have
> > > identified 3 choices so far.
> > >
> > > 1 - [] Put V2 doc changes in V1 pages and mark them as such
> > > 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> > > current
> > > site wiki
> > > 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
> > >
> > > Are there other cunning options we need to consider. I'm for option 2
> at
> > > the
> > > current time.
> > >
> > > Simon
> > >
> >
> > How would that option [2] actually work?
> >
> > Lets say I change the way the dwr binding works and want to update the
> doc
> > for V2, the current wiki page is at
> > http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what
> > would
> > i do for the new v2 page?
> >
> > ...ant
>
>
> You would make
> http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html<
> http://incubator.apache.org/tuscany/sca-java-bindingajax.html>.
> Copy the existing contents there. Edit them which whatever change you need
> to make and and then add a link to this page to the V2 index (which I
> expect
> will, by default, link to the existing pages).
>
> Simon
>
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 9, 2008 at 5:03 PM, ant elder <an...@gmail.com> wrote:
> On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <hm...@gmail.com> wrote:
> >
> > > +1 on versioning SCA docs
> > >
> > > Assuming two versions of SCA Java, I can see that the following page
> > will
> > > change to point to two different versions of SCA Java, 1.x and 2.x and
> > > their
> > > related documentation.
> > >
> > >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> > >
> > > Tuscany SCA Java general page would contain general information that
> > would
> > > pertain to both versions. So, it might need to change.
> > > http://incubator.apache.org/tuscany/sca-java.html
> > >
> > > On the left navigation of sca-java page, we would have two boxes
> > > SCA Java 2.x
> > > SCA Java 1.x
> > >
> > > each would point to their own releases and their own documentations
> and
> > > source code tree.
> > >
> > > There is a set of documentations under SCA Java that are generic, like
> > > development guide. We could share these pages between the two
> versions.
> > >
> > > Does this make sense?
> > >
> > >
> > Generally make sense to me.
> >
> > On the particular question of where to host V2 and V2 docs we have
> > identified 3 choices so far.
> >
> > 1 - [] Put V2 doc changes in V1 pages and mark them as such
> > 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> > current
> > site wiki
> > 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
> >
> > Are there other cunning options we need to consider. I'm for option 2 at
> > the
> > current time.
> >
> > Simon
> >
>
> How would that option [2] actually work?
>
> Lets say I change the way the dwr binding works and want to update the doc
> for V2, the current wiki page is at
> http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what
> would
> i do for the new v2 page?
>
> ...ant
You would make
http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html<http://incubator.apache.org/tuscany/sca-java-bindingajax.html>.
Copy the existing contents there. Edit them which whatever change you need
to make and and then add a link to this page to the V2 index (which I expect
will, by default, link to the existing pages).
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <si...@googlemail.com>
wrote:
> On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <hm...@gmail.com> wrote:
>
> > +1 on versioning SCA docs
> >
> > Assuming two versions of SCA Java, I can see that the following page
> will
> > change to point to two different versions of SCA Java, 1.x and 2.x and
> > their
> > related documentation.
> >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> >
> > Tuscany SCA Java general page would contain general information that
> would
> > pertain to both versions. So, it might need to change.
> > http://incubator.apache.org/tuscany/sca-java.html
> >
> > On the left navigation of sca-java page, we would have two boxes
> > SCA Java 2.x
> > SCA Java 1.x
> >
> > each would point to their own releases and their own documentations and
> > source code tree.
> >
> > There is a set of documentations under SCA Java that are generic, like
> > development guide. We could share these pages between the two versions.
> >
> > Does this make sense?
> >
> >
> Generally make sense to me.
>
> On the particular question of where to host V2 and V2 docs we have
> identified 3 choices so far.
>
> 1 - [] Put V2 doc changes in V1 pages and mark them as such
> 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> current
> site wiki
> 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
>
> Are there other cunning options we need to consider. I'm for option 2 at
> the
> current time.
>
> Simon
>
How would that option [2] actually work?
Lets say I change the way the dwr binding works and want to update the doc
for V2, the current wiki page is at
http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what would
i do for the new v2 page?
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <hm...@gmail.com> wrote:
> +1 on versioning SCA docs
>
> Assuming two versions of SCA Java, I can see that the following page will
> change to point to two different versions of SCA Java, 1.x and 2.x and
> their
> related documentation.
>
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
>
> Tuscany SCA Java general page would contain general information that would
> pertain to both versions. So, it might need to change.
> http://incubator.apache.org/tuscany/sca-java.html
>
> On the left navigation of sca-java page, we would have two boxes
> SCA Java 2.x
> SCA Java 1.x
>
> each would point to their own releases and their own documentations and
> source code tree.
>
> There is a set of documentations under SCA Java that are generic, like
> development guide. We could share these pages between the two versions.
>
> Does this make sense?
>
>
Generally make sense to me.
On the particular question of where to host V2 and V2 docs we have
identified 3 choices so far.
1 - [] Put V2 doc changes in V1 pages and mark them as such
2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
site wiki
3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
Are there other cunning options we need to consider. I'm for option 2 at the
current time.
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by haleh mahbod <hm...@gmail.com>.
+1 on versioning SCA docs
Assuming two versions of SCA Java, I can see that the following page will
change to point to two different versions of SCA Java, 1.x and 2.x and their
related documentation.
http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
Tuscany SCA Java general page would contain general information that would
pertain to both versions. So, it might need to change.
http://incubator.apache.org/tuscany/sca-java.html
On the left navigation of sca-java page, we would have two boxes
SCA Java 2.x
SCA Java 1.x
each would point to their own releases and their own documentations and
source code tree.
There is a set of documentations under SCA Java that are generic, like
development guide. We could share these pages between the two versions.
Does this make sense?
On 4/9/08, Simon Laws <si...@googlemail.com> wrote:
>
> On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker <da...@gmail.com> wrote:
>
> > ant elder wrote:
> >
> > > On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <si...@googlemail.com>
> > > wrote:
> > >
> > > We may need to branch the documentation also. Normally I would suggest
> > > that
> > >
> > > > we ask for a new space but as our documentation could not be
> > > > considered
> > > > complete for 1.1 and as the suggested first actions are internal
> > > > restructuring we may find it less onerous to maintain 2.X documents
> > > > alongside the the 1.X documents with suitable comments to point out
> > > > where
> > > > they diverge. Do people have a preference.
> > > >
> > > >
> > > > I wondered about the doc too, if there was a new wiki space for 2.x
> > > could it
> > > be initially be populated with the existing content? If so then it
> seems
> > > to
> > > me like it would be easiest to have the new space than to try point
> out
> > > the
> > > differences for each release all in the one space.
> > >
> >
> >
> > +1 on versioning and branching the docs and the wikis. Customers on
> older
> > levels will want to see the proper docs, configs, and samples for their
> > version, and customers on newer levels will want to see proper docs,
> > configs, and samples for their version. We should support them both.
> >
> > (This is also how the Geronimo team is tacking docs and samples.)
> >
> > --
> > Thanks, Dan Becker
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> If the concensus is for a completely separate space then it would seem
> that
> we need a new space to hold just Java SCA V2 docs (The current site space
> holds all the pages for all of the Tuscany projects). Maybe we want to
> reorganize along the same lines as Geronimo e.g. multiple spaces such as
>
> Apache Tuscany - our current site wiki
> Apache Tuscany SCA Java V1
> Apache Tuscany SCA Java V2
>
> I still slightly favour creating a "V2 Documentation" page on the existing
> wiki and populate it as and when required for the time being though.
>
> Simon
>
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker <da...@gmail.com> wrote:
> ant elder wrote:
>
> > On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <si...@googlemail.com>
> > wrote:
> >
> > We may need to branch the documentation also. Normally I would suggest
> > that
> >
> > > we ask for a new space but as our documentation could not be
> > > considered
> > > complete for 1.1 and as the suggested first actions are internal
> > > restructuring we may find it less onerous to maintain 2.X documents
> > > alongside the the 1.X documents with suitable comments to point out
> > > where
> > > they diverge. Do people have a preference.
> > >
> > >
> > > I wondered about the doc too, if there was a new wiki space for 2.x
> > could it
> > be initially be populated with the existing content? If so then it seems
> > to
> > me like it would be easiest to have the new space than to try point out
> > the
> > differences for each release all in the one space.
> >
>
>
> +1 on versioning and branching the docs and the wikis. Customers on older
> levels will want to see the proper docs, configs, and samples for their
> version, and customers on newer levels will want to see proper docs,
> configs, and samples for their version. We should support them both.
>
> (This is also how the Geronimo team is tacking docs and samples.)
>
> --
> Thanks, Dan Becker
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
If the concensus is for a completely separate space then it would seem that
we need a new space to hold just Java SCA V2 docs (The current site space
holds all the pages for all of the Tuscany projects). Maybe we want to
reorganize along the same lines as Geronimo e.g. multiple spaces such as
Apache Tuscany - our current site wiki
Apache Tuscany SCA Java V1
Apache Tuscany SCA Java V2
I still slightly favour creating a "V2 Documentation" page on the existing
wiki and populate it as and when required for the time being though.
Simon
Re: SCA 2.0, was Re: Next SCA release
Posted by Dan Becker <da...@gmail.com>.
ant elder wrote:
> On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> We may need to branch the documentation also. Normally I would suggest that
>> we ask for a new space but as our documentation could not be considered
>> complete for 1.1 and as the suggested first actions are internal
>> restructuring we may find it less onerous to maintain 2.X documents
>> alongside the the 1.X documents with suitable comments to point out where
>> they diverge. Do people have a preference.
>>
>>
> I wondered about the doc too, if there was a new wiki space for 2.x could it
> be initially be populated with the existing content? If so then it seems to
> me like it would be easiest to have the new space than to try point out the
> differences for each release all in the one space.
+1 on versioning and branching the docs and the wikis. Customers on
older levels will want to see the proper docs, configs, and samples for
their version, and customers on newer levels will want to see proper
docs, configs, and samples for their version. We should support them both.
(This is also how the Geronimo team is tacking docs and samples.)
--
Thanks, Dan Becker
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@apache.org>.
On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <si...@googlemail.com>
wrote:
<snip>
We may need to branch the documentation also. Normally I would suggest that
> we ask for a new space but as our documentation could not be considered
> complete for 1.1 and as the suggested first actions are internal
> restructuring we may find it less onerous to maintain 2.X documents
> alongside the the 1.X documents with suitable comments to point out where
> they diverge. Do people have a preference.
>
>
I wondered about the doc too, if there was a new wiki space for 2.x could it
be initially be populated with the existing content? If so then it seems to
me like it would be easiest to have the new space than to try point out the
differences for each release all in the one space.
...ant
Re: SCA 2.0, was Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
I'm +1 on this. Comments in line
Simon.
> >
> > - 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.
>
I propose that we create the branch for 1.x develop directly after 1.2 is
out to make clear our intentions. It's not clear if the suggestion here is
to create sca-java-1.X or sca-java-1.3. My vote would be for the latter
(reserving sca-java-1.2.1 in case we need to address specific concerns in
1.2 that are not subject to ongoing maintenance activities).
> > Thoughts ?
>
We may need to branch the documentation also. Normally I would suggest that
we ask for a new space but as our documentation could not be considered
complete for 1.1 and as the suggested first actions are internal
restructuring we may find it less onerous to maintain 2.X documents
alongside the the 1.X documents with suitable comments to point out where
they diverge. Do people have a preference.
Re: SCA 2.0, was Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
Yep, this is exactly what i'm was suggesting, was just leaving the name till
later :)
...ant
On Tue, Apr 8, 2008 at 5:27 PM, Luciano Resende <lu...@gmail.com>
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
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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
Re: SCA 2.0, was Re: Next SCA release
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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