Another question comes to mind, how will we handle issues found in the
"do-not-use" kernel if they are found by extension writers and are blocking? Do
they get fixed ? Parallel development on both kernels? Blocking till the new
kernel is ready?
Jim Marino 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]
