Will there be an svn a tag or branch of the "do-not-use" kernel so the extension
writers have something to debug with ? For those developers, I assume that the
procedure then is to check out their extension code from SVN at the HEAD, check
out the "do-not-use" kernel parts with svn tag version of "do-not-use" to have
matching source?
Jim Marino wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
