+1 I'll wait for 2 JIRAS to get in and I'll work with a commiter to get DAS branch created.
- Luciano Resende On 10/12/06, Rick <[EMAIL PROTECTED]> wrote:
Generally favorable. Essentially +1 if it were a vote. I have one concern is on the sca deliverables. We need to drive to a conclusion soon to figure out the exact artifacts a user will download and what each will contain. Not directly, related to the branching, but you did touched on it. Jeremy Boynes wrote: > We have had quite a few suggestions over the last couple of days for new > functionality for the trunk some of which would result in changes to the > APIs. We have also had the completion of one of the major pieces of code > (async over axis webservices) that was still outstanding although there > are still concerns over the amount of test coverage it has. We also have > RC distros of both SDO and DAS available. > > I am concerned that there is enough pent-up energy in the project that > we may soon see more changes that will destabilize what we have right > now. In light of that, I would like to suggest that we create a branch > where we can finish stabilizing M2 so that we can open the trunk for new > development without concern that it will disrupt a release. This matches > what has already been done for SDO. > > The alternative is to initiate a code-freeze until the M2 release is > tagged saying that all new work should be done in people's sandboxes. > This code-freeze is likely to be in place for a while as we also need to > wait for Axis2 1.1 to be released. I believe that would be less > acceptable and so unless there is an objection I plan to go down the > branch path. > > Just for the record (and people reading this later), the purpose of this > branch is to stabilize a milestone. The intention is not to establish a > branch for the purpose of ongoing maintenance and once the release is > tagged work on the branch will end. It can always be reopened later if > someone wants to restart work on it but that is not the intention at > this time. > > The SDO code already has a branch in place and we have basically stable > versions of the build support artifacts. In light of that, rather than > copy the entire source tree I'm going to create branches for each of the > source distributions that we intend to produce as follows: > > tags/java/pom/parent/1-incubator > tags/java/buildtools/1.0-incubator-M2 > tags/java/spec/sca-api/1.0-incubator-r0.95-M2 > branches/sdo-java-M2 (already there) > branches/das-java-M2 > branches/sca-java-M2 > > I moved the tags to a "java" subdirectory as I think over the course of > time we will be tagging quite a few things and if we put them all in one > directory it is going to get confusing. > > The pom/parent and buildtools tags will correspond to the current > version in the trunk. These are pre-reqs for all the other projects and > as such I would like to finalize their release early. I'm going to > re-initiate the vote from last week based on the new tags. > > Once the parent POM is tagged, SDO and DAS can be updated to use it and > eliminate all SNAPSHOT dependencies. If they are ready to go, we can > initiate a vote on them either together or separately (my inclination is > separately as different people may review them). > > SCA is a little more complex as we have outstanding issues related to > the distribution layout, what's in each distro (code, samples, doco > etc.) and so forth. As such I do not intend to just copy the entire SCA > tree but instead to build it up as these issues get resolved. This will > allow us to move things like the samples around in the trunk without > needing to duplicate work that in the branch (so we only do it once). > > Once a module is copied to the branch, the version in the trunk will be > bumped to 1.0-incubator-SNAPSHOT (removing the M2 designation). This > will ensure that there are no conflicts in between things built from the > branch and things built from the trunk (as artifacts from both will be > placed in your local repo). > > The first modules copied to the branch will be those needed to support > the standalone and webapp runtimes. This will include the kernel, > commands, runtime modules and the webapp plugin. > > The second wave of modules copied would be those for extensions that we > decide are /IN/ the release. The only reason these are separate from the > first ones is that we have not defined yet how they will finally be > packaged (just that they will be in a binary form). The ones I believe > that are currently in this category are: > * binding.axis2 > * binding.rmi > * idl.wsdl > * databinding.sdo > * databinding.axiom > > I am not sure on whether javascript, jsonrpc, ruby or spring fall in > this category or the next - opinions? > > A third set of modules will be distributed in source form only. This > includes groovy, castor, jaxb, xmlbeans and celtix. > > Finally, we need to decide how we will distribute supplemental artifacts > such as javadoc, end-user doc and samples. Once we know that, they can > be added to the branch in the appropriate places. > > Thanks for reading this far. > -- > Jeremy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
