On Sun, 2003-10-05 at 07:26, Jean-Francois Arcand wrote:Hi Robert,
robert burrell donkin wrote:
hi Jean-Francois
i'm very reluctant to apply a patch that breaks backwards compatibility but i'd be happier to deprecate them.
That was my initial response too. However it seems that the current code is actually broken/unreliable. Is it worse to remove code without the usual deprecation stage, or leave known-broken code in a release?
we always deprecate. one of the reasons why jakarta-commons has a good reputation is the rule no code is removed with first being deprecated. this sometimes means an extra release but this is a small price to pay. (see later for the some reasons why users appreciate this process.)
I'm not sure I would prefer to have an application fail to work correctly than to fail to compile...
when you're talking about backwards compatibility, the needs of the many often out weight the needs of the few. digester is now mature and is used (both directly and indirectly) in many applications. breaking backwards compatibility means that we will force users to recompile all these applications if they want any new bug fixes in future release. this process can often be very painful - or even impossible (think about proprietary software using a particular library version).
i did consider the alternatives. the existing code works for some versions of xerces - but not all. the users which are using this code must be using compatible versions. i've proposed an approach that should be able to retain backwards compatibility whilst also allowing a wider range of parsers to be supported. coupled with deprecation and documentation i believe that this will satisfy the needs of both new and existing users.
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
