Lars Kühne wrote:
On Jan 14, 2008 8:05 PM, Alan D. Cabrera wrote:
On Jan 14, 2008, at 4:35 AM, Rick McGuire wrote:
What cleanup steps need to be taken with the yoko code now that it's
been made a subproject in Geronimo? The first obvious one would be
to remove the non-core components from the trunk. The second would
be to remove the "incubating" from the version names.
Agreed
+1
Is JDK 1.4 still a given or has geronimo upgraded it's JDK dependency
to 1.5 since yoko entered the incubator? We shouldn't change the
required JDK in a point release, so this seems like a good time to
revisit this decision.
I think this might be a good time to revisit this, though I'd be
reluctant to put out a release without running it through the TCK
first. Since the only TCK we have is the full Geronimo TCK this sort of
needs to be coordinated with a Geronimo release. For the current
Geronimo release that's in the works, we've checked a specific revision
build into the Geronimo repository, so that's what it is running with.
The current code was never made into an official Yoko release.
Should we attempt to get this out as an official v1 release as soon
as the basic cleanup is completed?
I think that some people had some concerns about a release but I think
that they were more focused on proper documentation and releasing a
well rounded product.
That was me. My concern wasn't so much about user docs but developer
level documentation, see the "Answer this question..." yoko issues in
jira. Those questions mostly about being able to attract new
developers.
It's my opinion that it's ok to release so long
as the code is good enough. With that said, I would like to make a
1.0 release.
Yes, the code could use some cleanup but it does pass certification
and we can always improve things later, in another release.
This of course assumes that we don't have to pay too much attention to
backward compatibility. Does each follow-up version have to be a
drop-in replacement of the first 1.0 release? Or is it OK to change
ORB properties and such, as long as the changes are documented in the
release notes (which is what I hope, but I don't know the requirements
of Geronimo and Harmony)?
Generally, since Geronimo gets built and shipped with a specific release
dependency, it's ok to break compatibility if there is a good reason for
doing so. Of course, since Yoko is now part of Geronimo, the person
breaking the compatibility also needs to be responsible for any Geronimo
build breakages that occur. I think Harmony tends to adhere closer to
the OMG standards in terms of its usage, so it's less of an issue.
Geronimo uses a couple of hooks that were put in place to allow it to
integrate CSIv2 and RMI support into Geronimo. These can be changed as
long as the Geronimo code is fixed in parallel.
Rick
Regards,
Lars
