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]