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]
