Re: [Springframework-developer] method deprecation and backward compatibility in 1.2

[Juergen H. <ju...@in...>]

Well, the current policy I've applied for 1.2 is to remove all deprecated
classes and methods whose deprecation dates back to before 1.1 final. For
everything afterwards, I've kept backwards compatibility as far as possible.

In the case of AbstractXsltView, I'm not 100% sure. It would be ideal to
clearly mark methods that have to be implemented in subclasses as abstract,
but on the other hand, breaking backwards compatibility isn't desirable
either...

I guess it would be best to keep the deprecated "createDomNode" method for
now, and remove it in 1.3 RC1.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Darren Davison
Sent: Saturday, March 12, 2005 12:17 PM
To: spr...@li...
Subject: [Springframework-developer] method deprecation and backward
compatibility in 1.2


What's the official line on deprecating methods or retaining complete
backward compatibility in 1.2?

Example:
I've made changes to AbstractXsltView to allow it work with Source
implementations rather than Nodes which is more flexible (see SPR-730),
but I've kept the createDomNode() method for BC.

Problem is, subclasses MUST override/implement one of the methods only,
but I can't make either of them abstract in the superclass to enforce
this unless I remove createDomNode and make the new createXsltSource
abstract.  This would break existing projects that dropped
spring-1.2.jar into them.

For now, I've deprecated createDomNode but I wondered if we have an
agreed policy on what 1.2 means in terms of BC / deprecation.

Cheers,

--
Darren Davison
Public Key: #DD356B0D