End Of Life Procedures

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Current revision (12:37, 7 May 2019) (edit) (undo)
(Have You Ever Wondered...?)
 
(2 intermediate revisions not shown.)
Line 1: Line 1:
-
This section is good, and reminiscent of (symmetric to?) your section at the beginning of Part 3, "An API Must ...".
+
== [[Have You Ever Wondered]]...? ==
-
One thing I would recommend: an additional section of this chapter about communicating and distributing one's API. In my experience, a number of people have developed APIs which may be either good or bad, but which I have little chance of knowing, because it's presented so badly as to discourage me from investigating further, thereby rendering all of the work that went into the API somewhat useless. I know this isn't purely a software thing, but I think communicating an API clearly - what it does, what its limitations are, how it works!!! - is very important.
+
Is it not true, that by keeping compatibility we grow the number of APIs we have to maintain? For how long can this be sustained? Will not we all spend our lives maintaining old APIs instead of developing new functionality? Not necessarily. If you know how to use end of life procedures as described in [[End Of Life Procedures|Chapter 19]], you can send you old APIs to [[black hole]] smoothly while keeping [[BackwardCompatibility]].
-
 
+
-
--[[User:Dmkoelle|Dmkoelle]] 02:56, 23 April 2008 (UTC)
+
-
 
+
-
"... but also whole packages like java.beans.beancontext that are there without any further reason." Why? This package has not been deprecated AFAIK and it may still be quite useful to some.
+
-
 
+
-
--[[User:TomWheeler|TomWheeler]] Wed Apr 23 20:38:48 CDT 2008
+
-
 
+
-
what is "paste jewelry"?
+
-
 
+
-
--[[User:Richunger|Richunger]] 05:23, 26 April 2008 (UTC)
+

Current revision

Have You Ever Wondered...?

Is it not true, that by keeping compatibility we grow the number of APIs we have to maintain? For how long can this be sustained? Will not we all spend our lives maintaining old APIs instead of developing new functionality? Not necessarily. If you know how to use end of life procedures as described in Chapter 19, you can send you old APIs to black hole smoothly while keeping BackwardCompatibility.

Personal tools
buy