Hi,
It seems the JCS folks are (now) thinking of preparing a release. Given this will be their first release, and this change will be in the release, does it seem prudent for Cocoon to track this change now, and get as much testing time as possible?
regards
Adam -- Have you Gump'ed your code today? http://gump.apache.org
---------- Forwarded message ---------- Date: Tue, 10 Aug 2004 08:51:42 -0700 From: "Smuts, Aaron" <[EMAIL PROTECTED]> Reply-To: Turbine JCS Developers List <[EMAIL PROTECTED]> To: Turbine JCS Developers List <[EMAIL PROTECTED]> Subject: RE: Cocoon and JCS (on Gump)
Yes. We can release. All the known bug fixes and the improvements that we wanted to get done first have been completed.
I need to find out the process.
Aaron
-----Original Message----- From: Estefano Eduardo [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 10, 2004 2:13 AM To: Turbine JCS Developers List Subject: RE: Cocoon and JCS (on Gump)
I think the problem is that there are no releases of JCS yet, so this is not possible. If you update your cvs repository you may be getting stuff that will break your working code.
Isn't JCS stable enough for a Beta version release? This way other applications could know what what they are getting into through the release notes, change logs, etc.
-----Original Message----- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Monday, 09 August, 2004 23:01 To: Turbine JCS Developers List Cc: [EMAIL PROTECTED] Subject: RE: Cocoon and JCS (on Gump)
On Mon, 9 Aug 2004, Travis Savo wrote:
According to the change log Aaron Smuts made this change on 6/28/2004 in order to make .dispose() visible to the clients of the JCS class.
I expect it will be a permanent change because it's reasonable that clients of the JCS class will want to dispose of a region themselves.
The only problems I foresee with upgrading this in the field is if there's a class that extends CacheAccess (which you appear to be doing). In this case you will need to upgrade your code, but I expect this to be an isolated and rare occurrence. Assuming that's not the case, I see no problems mixing jars in the field in relationship to this change.
Does that answer your question?
First, thanks for the answer. Second, API changes happen (fact of life), and Gump (and my questions) are just trying to see if we can mitigate against issues in the field, be early detection and discussion/etc.
Frankly, my low level java is insufficient to know if subtleties of access contraints (on a method) make it into the signature, and/or otherwith affect runtime. I could imagine that such a change annoys compilers, but slides through at runtime (in many case).
I don't think there is an easy way for anybody to allow a transition path, given this type of change. As such, I suspect the correct approach is to note it, and try to move on. BTW: What would really help is notice of what releases the old 'signature' is in, and what release the new one might be in. Having this be in the RELEASE NOTES could help also. Could you answer that question, and try to remember it for the CHANGES notification.
BTW: I'll CC the cocoon community on this one, to see if they are comfortable changing their code.
Thanks for your help.
regards
Adam
--------------------------------------------------------------------- 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]
