Mailing-List: contact turbine-jcs-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Turbine JCS Developers List" <turbine-jcs-dev@jakarta.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Cocoon and JCS (on Gump)
Date: Tue, 10 Aug 2004 08:51:42 -0700
Message-ID: 
 <D86E461BA12FEE42982B0232D62DDD3505AAE8B8@ex-mail-sea-03.ant.amazon.com>
Thread-Topic: Cocoon and JCS (on Gump)
Thread-Index: AcR+VAVNmZ+FIeKvRRa0rsf3sCHIUwAZaQfgAA4BR7A=
From: "Smuts, Aaron" <aaronsm@amazon.com>
To: "Turbine JCS Developers List" <turbine-jcs-dev@jakarta.apache.org>

Yes.  We can release.  All the known bug fixes and the improvements that =
we wanted to get done first have been completed. =20

I need to find out the process.

Aaron=20

-----Original Message-----
From: Estefano Eduardo [mailto:eduardo.estefano@siemens.com]=20
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:ajack@apache.org]
Sent: Monday, 09 August, 2004 23:01
To: Turbine JCS Developers List
Cc: dev@cocoon.apache.org
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=20
> 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=20
> 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=20
> there's a class that extends CacheAccess (which you appear to be=20
> doing). In this case you will need to upgrade your code, but I expect=20
> this to be an isolated and rare occurrence. Assuming that's not the=20
> case, I see no problems mixing jars in the field in relationship to=20
> 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: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org