You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/10/12 01:49:56 UTC
Stabilizing M2 for release
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Stabilizing M2 for release
Posted by Raymond Feng <en...@gmail.com>.
Thanks to Jeremy to clearly state the objective and explain the strategy.
+1 from me.
Raymond
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Wednesday, October 11, 2006 4:49 PM
Subject: Stabilizing M2 for release
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Stabilizing M2 for release
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Stabilizing M2 for release
Posted by Venkata Krishnan <fo...@gmail.com>.
Hi Jeremy, thanks for that explanation... was really useful.
I think Javascript and maybe even Ruby should be in.
Javascript has been up and working for long now. I found it to be a good
demonstration of a container extension and that is how I ended up doing Ruby
quickly (by my standards :)). It has...
- properties, services and references working
- extends to support E4X
- has an acceptable test coverage
- has a working sample
Maybe the doc is something that remains to be done or maybe that is also
there and am missing that.
Thanks
- Venkat
On 10/12/06, Luciano Resende <lu...@gmail.com> wrote:
>
> +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 <cr...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
Re: Stabilizing M2 for release
Posted by Luciano Resende <lu...@gmail.com>.
+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 <cr...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Stabilizing M2 for release
Posted by Rick <cr...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Stabilizing M2 for release
Posted by Andy Piper <an...@bea.com>.
At 00:49 12/10/2006, Jeremy Boynes wrote:
>I am not sure on whether javascript, jsonrpc, ruby or spring fall in
>this category or the next - opinions?
Spring is stable enough IMO. I have some changes planned, but
probably not in time for M2 and the existing code works ok (and is
mostly structured ok).
andy
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org