On Oct 11, 2006, at 4:49 PM, 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.
I'm assuming this means no API changes or new additions to the
branch, save the async work and bug fixes? I agree branching may be
the best solution at this point as the release has dragged out. Also,
we're going to have some significant refactoring that needs to be
done to accommodate spec changes and support things like multi-vm
deployment, dynamic service discovery, and stateful conversations
that I'd like to get started on soon.
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.
I agree. This would also be a mess to make sure people stay in sync.
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.
+1
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).
I'd be happy not to hold up the SDO and DAS releases. If they are
ready then it seems like a good thing not to wait for Java SCA.
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?
I'd like to release Spring but I'll defer to Andy's opinion on this.
One concern I have with it is low test coverage but then that seems
to be a more general problem. Perhaps M3 can be in part a hardening
release? :-)
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.
For samples, I sent a proposal to the list yesterday which didn't
elicit any comments. As release manager, could you take a look at see
if it aligns with what your are thinking here (I believe it mostly
does). Hopefully others can comment as well or propose an alternative.
Thanks for reading this far.
Hey, I'll event throw in a gratuitous comment: thanks for outlining
this in such depth!
Jim
--
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]
