1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
December, 07/2002
How to deal with removed extensions
A) removed extensions _without_ replacement
1.) the extension relies on external libraries no longer
available:
- keep ext/reference.xml containing only a short note about the
removal, the reason and when (Version information)
- exclude the functions from the build process modifying manual.xml.in
- delete the docs (expect ext/reference.xml), because they are not
longer (even for historical reasons) of any use.
2.) the extension relies on external libraries still
available:
- modify ext/reference.xml containing a short note about the
removal, the reason and when (Version information)
- keep the docs for some time, because older versions of PHP will
still work with this extension and maybe some people out there are
using this extension.
- after some time same procedure as 1.)
B) removed extensions _with_ replacement
1.) make sure php.net/removed_extension points to php.net/replacement
2.) exlude the extension from the build process, modifying manual.xml.in
3.) put a note in replacement/reference.xml
Take ext/icap as example:
1.) php.net/icap points the user to php.net/mcal
2.) php.net/mcal: reference.xml contains a note about the suggested
replacement.
KEEP IN MIND:
Delete all links to removed extensions/functions from the docs.
Inform all translation teams about the changes. Encourage them,
to clean up
- their docs
- their CVS-tree
Just for the docs, it would be nice if the cleanup could be done
automatically.
|
