geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: [YOKO]
Date Tue, 15 Jan 2008 15:12:15 GMT
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.

> Regards,
> Lars

View raw message