> -----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.
> >
> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
