On 10/2/06, Olavo Santos <[EMAIL PROTECTED]> wrote:
Just a quick side note.
Many "deprecation sign for any user" are clearly signs that Zope
developers are unable to maintain certain Zope features. This is bad,
specially for guys that have to manage large, complex and long time running
zope installations ( think years ). And a "no sir, next app!" for guys like
us who have to choose opensource development platforms for the long run (
again: think years ).
Well, though nothing is perfect in Zope world, I think we are quite
good in having a policy about deprecation which already gives a
guaranteed timelime for deprecation.
I wanted to find a deprecation policy for eclipse and JBoss to
compare. For JBoss i did not find such a thing, for eclipse I did not
find a eclipse framework one, but one for some sub projects:
and somehow this popped up in the eclipse search result:
Notice especially how they mention that a deprecation phase can be days.
So for me it looks we are actually a bit ahead of the competition, but
maybe somebody can correct me.
Accidently I lately tripped over an article from Martin Fowler about this topic:
I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it
makes sense to have a smaller core API with longer deprecation
periods, so that standard projects can try to rely on core API with
long deprecation phase and extender would use the one year deprecation
phase. But as I said earlier, I think we are quite ahead already.
I guess the motivation of this API stability discussion is also
motivated by JMOs comment about how much more stable is the Java API,
in Point 2 and 3 of this entry:
But it is not fair to compare the stability of a programming language
standard modules API with a application framework api. But maybe I am
not good in searching and somebody points me to the well thought out
JBoss or Websphere deprecation policy
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -