haleh mahbod wrote:
Hi Jim,
I don't understand what you mean when you talk about the " do-not-use"
kernel version.
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
Step #2 is a release of existing extensions on the Kernel - At this point
Kernel and extensions can be used by users
Step #3 is kernel evolving in the trunk to sync up with latest spec
changes
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 #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
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]
+1
I think this is a very good plan. It will allow the kernel to evolve and
start implementing spec changes, and at the same time provides the
stable base that the rest of the project needs to scale.
Will there be a list of features from the POJO C&I and assembly spec
supported / not supported by the internal-use kernel release?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
