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: [EMAIL PROTECTED] > > 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] > > 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
