Re: SCA 2.0, was Re: Next SCA release
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 [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30237.html
Re: SCA 2.0, was Re: Next SCA release
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
Re: SCA 2.0, was Re: Next SCA release
On Thu, Apr 10, 2008 at 4:43 AM, Mark Combellack [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA 2.0, was Re: Next SCA release
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: [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. 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]
Re: SCA 2.0, was Re: Next SCA release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
