End Of Life Procedures - Revision history

JaroslavTulach: /* Have You Ever Wondered...? */

2019-05-07T12:37:40Z

Have You Ever Wondered...?

←Older revision		Revision as of 12:37, 7 May 2019
Line 1:		Line 1:
	== [[Have You Ever Wondered]]...? ==		== [[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 [[End Of Life Procedures\|Chapter 19]], you can send you old APIs to black hole smoothly while keeping ~~backward compatibility~~.	+	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]].

JaroslavTulach at 20:10, 17 August 2008

2008-08-17T20:10:17Z

←Older revision		Revision as of 20:10, 17 August 2008
Line 1:		Line 1:
-	~~Send~~ you old APIs to black hole smoothly ~~with help of this chapter~~.	+	== [[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 [[End Of Life Procedures\|Chapter 19]], you can send you old APIs to black hole smoothly while keeping backward compatibility.

Apidesign: Replacing page with 'Send you old APIs to black hole smoothly with help of this chapter.'

2008-06-14T06:36:01Z

Replacing page with 'Send you old APIs to black hole smoothly with help of this chapter.'

←Older revision		Revision as of 06:36, 14 June 2008
Line 1:		Line 1:
-	~~This section is good, and reminiscent of (symmetric~~ to~~?) your section at the beginning of Part 3, "An API Must ...".~~	+	Send you old APIs to black hole smoothly with help of this chapter.
-		+
-	~~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.	+
-		+
-	~~--[[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)~~	+

Richunger at 05:23, 26 April 2008

2008-04-26T05:23:57Z

←Older revision		Revision as of 05:23, 26 April 2008
Line 8:		Line 8:

	--[[User:TomWheeler\|TomWheeler]] Wed Apr 23 20:38:48 CDT 2008		--[[User:TomWheeler\|TomWheeler]] Wed Apr 23 20:38:48 CDT 2008
		+
		+	what is "paste jewelry"?
		+
		+	--[[User:Richunger\|Richunger]] 05:23, 26 April 2008 (UTC)

Tomwheeler at 02:56, 24 April 2008

2008-04-24T02:56:00Z

←Older revision		Revision as of 02:56, 24 April 2008
Line 4:		Line 4:

	--[[User:Dmkoelle\|Dmkoelle]] 02:56, 23 April 2008 (UTC)		--[[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

Dmkoelle: New page: This section is good, and reminiscent of (symmetric to?) your section at the beginning of Part 3, "An API Must ...". One thing I would recommend: an additional section of this chapter abo...

2008-04-23T02:56:10Z

New page: This section is good, and reminiscent of (symmetric to?) your section at the beginning of Part 3, "An API Must ...". One thing I would recommend: an additional section of this chapter abo...

New page

This section is good, and reminiscent of (symmetric to?) your section at the beginning of Part 3, "An API Must ...".

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.

--[[User:Dmkoelle|Dmkoelle]] 02:56, 23 April 2008 (UTC)