Comments inline.
Simon
Simon Laws wrote:
On Thu, Apr 10, 2008 at 12:43 PM, Mark Combellack <[EMAIL PROTECTED]>
wrote:
-----Original Message-----
From: ant elder [mailto:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
wrote:
On Thu, Apr 10, 2008 at 8:12 AM, ant elder <[EMAIL PROTECTED]>
wrote:
On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
