I see I made a numbering mistake by not having a step 4...In any
event, I'll assume the original numbering (no step 4). Comments inline.
On Jan 17, 2007, at 9:05 PM, haleh mahbod wrote:
Hi Jim,
I don't understand what you mean when you talk about the " do-not-
use"
kernel version.
A "do-not-use" or "internal-use" kernel means a version which is not
intended for use outside the project by extenders. It is intended
only to provide a stable cut of kernel for extensions in Tuscany to
work from so they do not have to reference HEAD. As kernel evolves,
we may publish additional releases. My desire is that the next
release of kernel be stable enough that it becomes a distribution
others can use.
Here is how I am understanding your proposal. . Is this correct?
Step #1 in your list: is a release of the kernel with content as of
today .
This will live in a branch - Extensions will need to be sync'd up
on this
version
We don't need to branch to do this. We just cut the release from HEAD
and then continue development. Extensions will reference the release,
which will be in the Maven repo.
Step #2 is a release of existing extensions on the Kernel - At this
point
Kernel and extensions can be used by users
Step 2 involves having the extensions use the release and not HEAD.
It does not involve any other release (of extensions or kernel). This
will be done immediately after the release is posted to Maven.
Step #3 is kernel evolving in the trunk to sync up with latest spec
changes
Step 3 is evolving the kernel to implement the latest spec changes as
well as continue separate development of the extensions which refer
to the released version of kernel from Step 1. In other words,
development continues in parallel.
Step #4 is the follow on release of the kernel with the spec
changes -
Extensions will need to be sync'd up on this version.
Step 4 (improperly labeled step 5) involves a release of kernel. At
some point after that, the extensions will individually or in sets
move up to use that release. Extensions do not need to move at once
as they will be on individual development cycles.
Step #5 is the release of extensions on top of kernel in step 4- At
this
point the new Kernel and extensions can be used by users
Kernel will be "usuable" by end-users after step 4 as, we will be
cutting a kernel distribution. After that point, there will be
releases of extensions which will be done either individually or in
sets. For example, the Axis extensions (web services binding and
Java2WSDL tooling) may be released X days later. Followed by that,
maybe a week later if it is ready, the Spring extension will be
released. The key thing is we have a separate kernel release and
extensions are released on individual schedules.
Jim
Thanks,
Haleh
On 1/17/07, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi,
A few of us are participating in the SCA Assembly offsite this week.
The outcome of the offsite is that there will be a number of changes
introduced into the specification which will impact the kernel and
extensions. We can summarize and discuss the changes in separate
threads but I wanted to propose a way for handling these changes
which will allow kernel and extension development to proceed apace
while minimizing instability. This proposal is also intended to allow
us to introduce the remaining modularity changes that have been
previously discussed.
Specifically, I propose we initiate a release of kernel over the next
several days which serve as a baseline for extension development.
This release of kernel would be intended only for "internal"
extension development and not for end-users. The purpose of the
release is to allow kernel changes to be introduced without causing
instability in the extensions. Later, a stable kernel release will be
made which extensions will upgrade to. This release would be the
kernel release we have been discussing over the last couple of weeks.
When, extensions are ready, they would be released individually or in
sets.
I see this process happing in the following steps:
1. Release a "internal-use" kernel version, which will be initiated
over the next couple of days
2. Right after, switch extensions to build off the the "do-not-use"
kernel version
3. Continue development of kernel and extensions simultaneously. At
this point we also reorganize the build tree and extensions as we
previously described, grouping extensions and samples by how they
will be distributed
5. Release a version of kernel with a stable SPI (the Java kernel
release), incorporating the new SCA changes
6. Release extensions individually or in sets as they are ready
Comments/suggestions/thoughts?
Jim
---------------------------------------------------------------------
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]
