From: Samuel Mimram Date: Fri, 26 May 2006 13:12:50 +0000 (+0000) Subject: Improved the docbook policy. X-Git-Tag: archive/raspbian/4.08.1-4+rpi1~3^2~641^2~10 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=389edb4615dabf0a595cb69610c98de8558bbde3;p=ocaml.git Improved the docbook policy. --- diff --git a/Makefile b/Makefile index 1ad1903c..05f3a7fb 100644 --- a/Makefile +++ b/Makefile @@ -1,9 +1,12 @@ -%.html: %.xml - xsltproc --nonet --output $@ \ - /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/html/docbook.xsl \ - $^ +all: html text -all: ocaml_packaging_policy.html +html: + docbook2html ocaml_packaging_policy.xml -o packaging-policy-html + +text: + docbook2txt ocaml_packaging_policy.xml clean: - $(RM) ocaml_packaging_policy.html + $(RM) -rf packaging-policy-html ocaml_packaging_policy.txt + +.PHONY: html text diff --git a/appendix-resources.xml b/appendix-resources.xml index e69de29b..c5b1e4ef 100644 --- a/appendix-resources.xml +++ b/appendix-resources.xml @@ -0,0 +1,6 @@ +
+ Where to find the &ocaml-force; + + blah + +
diff --git a/appendix-transition.xml b/appendix-transition.xml index 8b137891..80a402f8 100644 --- a/appendix-transition.xml +++ b/appendix-transition.xml @@ -1 +1,6 @@ - +
+ Packages which can be binNMUed + + blah + +
diff --git a/authors.xml b/authors.xml index c566527a..26819dd7 100644 --- a/authors.xml +++ b/authors.xml @@ -22,8 +22,9 @@
sylvain.le-gall@polytechnique.org
- - The Debian OCaml Task Force -
debian-ocaml-maint@lists.debian.org
- - + + + The Debian OCaml Task Force +
debian-ocaml-maint@lists.debian.org
+ + diff --git a/chapter-generalities.xml b/chapter-generalities.xml new file mode 100644 index 00000000..a49a478b --- /dev/null +++ b/chapter-generalities.xml @@ -0,0 +1,120 @@ +
+ OCaml in Debian + + At the time of this writing, the latest version of OCaml in Debian is &ocaml-version;. + + + + The ocaml package depends on all the basic packages needed to develop programs with OCaml. More specifically, the packaging of OCaml is split into smaller packages. The -nox packages contain libraries which don't need X (i.e. for the programs which don't use the Graphics or LablTk modules) in order to avoid too big dependencies for users who don't have and X server installed. + + + + The ocaml and ocaml-nox package contain the compiler and its libraries. + + + + + The ocaml-native-compilers contains the OCaml compiler built in native mode. + + + + + The ocaml-base and ocaml-base-nox packages contain the runtime libraries needed by bytecode programs compiled with OCaml (in particular it contains the ocamlrun program). + + + + + The ocaml-interp contains the interactive command-line interpreter. + + + + + The ocaml-mode contains the OCaml emacs mode (the one provided with OCaml, not the tuareg mode). + + + + + The ocaml-source contains the sources of the OCaml compiler. + + + + + The ocaml-compiler-libs contains some internal libraries of the OCaml compiler (it is needed only in very rare cases). + + + + + + + Since the libraries produced by OCaml are binary incompatible when compiled with two different releases of OCaml, versionned virtual packages are provided: ocaml-&ocaml-version;, ocaml-nox-&ocaml-version;, ocaml-base-&ocaml-version;, ocaml-base-nox-&ocaml-version;. + +
+ +
+ Native and bytecode programs + + + The OCaml compiler can produce two kinds of executables: bytecode and native. The native executables (compiled with ocamlopt) are generally faster since they are compiled specifically for an achitecture. The bytecode executables (compiled with ocamlc) have the advantage of being portable, which means that a bytecode program can be run on any achitecture without needing to be rebuilt. It should be noted that native OCaml compilers are not provided for every achitecture. Only the following are suported: alpha, amd64, arm, i386, ia64, kfreebsd-i386, powerpc and sparc. + + + + Package providing both native and bytecode versions of a program prog usually name them respectively prog.opt and prog.byte and provide a symbolic link prog to the best available version (generally prog.opt). + + + + The ocaml-native-compilers package contains the OCaml compiler built in native mode (ocamlc.opt and ocamlopt.opt). Compiling with this version of the compiler is generally faster but, as explained before, the ocaml-native-compilers package is not available on every architecture. In order to build big programs and benefit from this natively built compiler, packages should depend on ocaml-best-compilers which depends on ocaml-native-compilers where available and on ocaml elsewhere. + +
+ +
+ Files used by the OCaml compiler + + + The &ocaml-name; compiler can produce or use the following kind of files: + + bytecode executables (they can be recognised since they start with #!/usr/bin/ocamlrun) + bytecode libraries (*.cma) + native executables (in ELF format) + native libraries (*.cmxa) + shared libraries (for C bindings) (dll*.so) + static libraries (for C bindings) (lib*.a) + bytecode object files (*.cmo) + native object files (*.cmx) + configuration files for handling libraries with ocamlfind (META) + &camlp4; related files (*.cm[ao]) + + +
+ +
+ Locally installing OCaml programs and libraries + + + Installation and use of locally installed OCaml related programs is out of the scope of this document. However, in order to have it work with a standard Debian installation, you should follow some guidelines. + + + + Executable files should be installed in /usr/local/bin. + + + + + Shared libraries (for C bindings) should be installed in /usr/local/lib/ocaml/&ocaml-version;/stublibs/ + + + + + Basically, every other file should be installed in /usr/local/lib/ocaml/&ocaml-version;/. This includes in particular bytecode libraries (*.cma), native libraries (*.cmxa), bytecode object files (*.cmo), native object files (*.cmx), static libraries (*.a) and META files. + + + + + + + The OCaml compiler first looks for a local installation of libraries and then for libraries installed by Debian packages. This section describe the standard paths for files contained in Debian packages. + + + + Warning: the + preceding any library in the of ocamlc or ocamlopt won't be expanded to the local standard library path. You need to specify the path entirely. + +
diff --git a/chapter-liblocal.xml b/chapter-liblocal.xml index 9234813d..e69de29b 100644 --- a/chapter-liblocal.xml +++ b/chapter-liblocal.xml @@ -1,70 +0,0 @@ - - Installation and use of locally installed &ocaml-name; is out of the - scope of this document. However, in order to have it work with a standard - &ocaml-name; &debian-name; install, you should follow some guideline. - - -
- Path of localy installed component - - Warning : the + preceding any library - in of &ocamlc;, &ocamlopt; wont be expanded - to the local standard library path. You need to specify this - path entirely. - - - You user this path to install local library and executable : - - - bytecoded executable - /usr/local/bin/ - /usr/local/sbin/ - - - bytecoded library ( *.cma ) - /usr/local/lib/ocaml/&ocaml-version;/ - - - native executable - /usr/local/bin/ - /usr/local/sbin/ - - - native library ( *.cmxa ) - - - shared library ( for C-binding ) ( dll*.so ) - /usr/local/lib/ocaml/&ocaml-version;/stublibs/ - - - static library ( for C-binding ) ( lib*.a ) - /usr/local/lib/ocaml/&ocaml-version;/ - - - bytecoded object ( *.cmo ) - /usr/local/lib/ocaml/&ocaml-version;/ - - - native object ( *.cmx ) - /usr/local/lib/ocaml/&ocaml-version;/ - - - configuration file for handling library ( META ) - /usr/local/lib/ocaml/&ocaml-version;/ and subdirectory - - /usr/local/lib/ocaml/&ocaml-version;/META - - - &ocamldoc; generated documentation ( *.odoc ) - /usr/local/share/ocamldoc-base - - - &camlp4; related files ( *.cm[ao] ) - /usr/local/lib/ocaml/&ocaml-version;/ and - subdirectory - - - - - -
diff --git a/chapter-libpack.xml b/chapter-libpack.xml index aae72177..3a8af2c8 100644 --- a/chapter-libpack.xml +++ b/chapter-libpack.xml @@ -1,3 +1,180 @@ -
- Camlp4 files -
+
+ Paths for libraries + + + Libraries should be installed in /usr/local/lib/ocaml/&ocaml-version;/ or in a subdirectory of this directory. This includes in particular bytecode libraries (*.cma), native libraries (*.cmxa), bytecode object files (*.cmo), native object files (*.cmx), static libraries (*.a) and META files. The only exception to this rule is for shared libraries (dll*.so) which should be installed in /usr/local/lib/ocaml/&ocaml-version;/stublibs, as can it be seen in the /usr/lib/ocaml/&ocaml-version;/ld.conf file. + + + + If upstream developpers already use a subdirectory of the OCaml standard library path, this path should be preserved in the Debian package but made relative to the standard library path of OCaml. Before using the provided subdirectory, packagers should obviously check if there is no subdirectory name clash with another OCaml library. + + + + If upstream developpers don't use this scheme, packagers are encouraged not + to install this library in the standard library directory. They should create + at least a subdirectory per source package (in order to avoid name clashes). Packagers should also consider to do a larger separation by creating a subdirectory per binary package (in order to avoid META name clash). + A suggested rule to choose name for this subdirectory is to use either the package + name provided by the META of the upstream, or the name of the library itself. + +
+ +
+ Providing <filename>META</filename> files + + + The ocaml-findlib provides a tool (named ocamlfind) to handle OCaml libraries and store information about libraries dependencies, compiler flags, linking options, etc. Meta informations regarding a library are contained in files (usually one for each library), named META files, contained in the library directory. The distribution of META files is the best way to make more easy to use the Debian-specific oragnization of libraries. Packages distributing META files should suggest the use of &ocamlfind;, that is have a Suggest: ocaml-findlib. + + + + By default, &ocamlfind; will look for META in this order: + + /usr/lib/ocaml/&ocaml-version;/META/ + /usr/lib/ocaml/&ocaml-version;/package/ + + + + + The naming scheme of META is pretty simple. + + + + If the META file is placed in the subdirectory + of the package, it should be called META. + + + + + If the META file is placed in /usr/lib/ocaml/&ocaml-version;/META/, it should be called META.packagename, where packagename is the name of the subdirectory where the library is stored. + + + + + + + For example, the META file for the lablgtk library is named META and has path /usr/lib/ocaml/&ocaml-version;/lablgtk/META, where /usr/lib/ocaml/&ocaml-version; is the main OCaml installation directory and lablgtk is the lablgtk library directory. + + + + If upstream doesn't provide a META, packagers are encouraged to create one. In this case, the META should be sent to upstream authors, in order to have it included in the next version of the upstream source. For more information about META files, have a look at the Findlib manual, at the several META files provided by other packages (e.g. lablgtk, pxp, pcre, netstring, lablgl, ...) or ask on the debian-ocaml-maint ML for help. + +
+ +
+ &ocamldoc; specific generated documentation + + + Even if this way of producing documentation is not mandatory, packagers are + encouraged to use it, in order to ship lighter documentation, which could + be processed by &ocaml-name; tools. + + + + By default, &ocamldoc-base; will look for *.odoc in this order : + + + local + /usr/local/share/ocamldoc/&ocaml-version;/ + + + core + /usr/share/ocamldoc/&ocaml-version;/ + + + + + + As for library, the naming scheme of the *.odoc should be + at least the name of the source package from which the documentation was + generated. If a source package is split in many binary package and the + documentation comes only in one *.odoc, packagers are + encouraged to create a separate package and to Suggest: it + in each binary package which he described. If this could not be met, it is at + least a good practice to Suggest: the package containing + the documentation. + The packager should consider to ship one *.odoc per + library package. + + + + By doing this, &ocaml-force; is trying to build a clear way of distributing + documentation. It should help user to find and exploit the documentation + coming from the source. Generating &ocamldoc; documentation is not so hard, + and should take a one line call. Commenting the code in order to generate + fully functional documentation is however an upstream task. Packager are encouraged + to patch Makefile in order to have a target + odoc, generating this documentation and to contact upstream + author to have a well commented source. + +
+ +
+ &camlp4; + + Actually, &camlp4; extensions are stored in + /usr/lib/ocaml/&ocaml-version;/camlp4/. In order to do something + cleaner, &ocaml-force; propose to put this files in their own directory, even in their + own package. It is not mandatory, but it could ease a lot, the user of camlp4, by avoiding + name clash. + + + + You just have to consider &camlp4; file just as standard library, except that you + prefix them with -syntax. For example: the syntax + extension coming with libokey-ocaml-dev should be stored + in /usr/lib/ocaml/&ocaml-version;/okey-syntax/, the package + containing it should be called libokey-syntax-ocaml-dev. + + + + It is recommended to use META to specify how to handle this + extension. + + + + All definition is taken from previous text considering syntax extension as a standalone + library. + + +
+ +
+ Documentation + + The documentation is a joint effort of &ocaml-force; and usptream. + There is many way to have documentation : + + Header files (*.mli) + Source files (*.ml) + Specific documentation provided by the upstream + OCamldoc generated documentation + + + + + This documentation should be browse by different mean, from the + most simple to the most complex. At least, they could all be browsed with + simple text editor. Specific and &ocamldoc; generated documentation should + be browse by using different viewer ( like advi, + HTML browser...). There is also at least two + specific &ocaml-name; browser : docbrowse shipped + with cameleon and ocamlbrowser + shipped with &ocaml-name; itself. The first one, need specific + &ocamldoc; generated documentation. The second one enables + the user to browse directly the prototype of each function shipped in the cmi gives + to the application. + + + + You can generate &ocamldoc; specific documentation by using + the of this application. By using this, you dump the + intermediary representation of the document that will be generated by ocamldoc. + This can be used to generate HTML documentation and manpages, by reloading this + file ( using ). + + + + As of today, there is no way to post-process &ocamldoc; + specific documentation. A &debian-name; package is under construction to do this + task. It will be referred as &ocamldoc-base;. + +
diff --git a/chapter-ocaml.xml b/chapter-ocaml.xml deleted file mode 100644 index fc23d65d..00000000 --- a/chapter-ocaml.xml +++ /dev/null @@ -1,306 +0,0 @@ -
- Version - - At any given time, the package &ocaml-pkg; should represent - the current stable upstream version of &ocaml-name; - revision &ocaml-version;. - - - - This package provides a virtual package called &ocaml-vpkg;. - This will help to track incompatible changes made within the - same version of &ocaml-name;. - - -
- -
- Base Package - - In order to have a minimal installation, a virtual package - &ocaml-base-vpkg; exists. It enable to have - a bare minimum install of &ocaml-name; library. - - - - As for &ocaml-pkg; this package provides - a virtual package &ocaml-base-vpkg;. This will help to track - incompatible changes made within the same version of &ocaml-name;. - - -
- -
- File terminology for Ocaml packaging - - - &ocaml-name; is a complete language allowing to create : - - bytecoded executable - bytecoded library ( *.cma ) - native executable - native library ( *.cmxa ) - shared library ( for C-binding ) ( dll*.so ) - static library ( for C-binding ) ( lib*.a ) - bytecoded object ( *.cmo ) - native object ( *.cmx ) - configuration file for handling library ( META ) - &ocamldoc; generated documentation ( *.odoc ) - &camlp4; related files ( *.cm[ao] ) - - - - - There is a convention considering that native executable should be - called progname.opt and bytecoded one - progname.byte. When packaging, only - progname is taken in account. - - - - For easying library management, &ocaml-force; used the - &ocamlfind; library management scheme. This scheme includes - a file named META which holds - all the library possibility. This is the configuration file for - handling library path and compile option. - -
- -
- Documentation - - The documentation is a joint effort of &ocaml-force; and usptream. - There is many way to have documentation : - - Header files ( *.mli ) - Source files ( *.ml ) - Specific documentation provided by the upstream - OCamldoc generated documentation - - - - - This documentation should be browse by different mean, from the - most simple to the most complex. At least, they could all be browsed with - simple text editor. Specific and &ocamldoc; generated documentation should - be browse by using different viewer ( like advi, - HTML browser ...). There is also at least two - specific &ocaml-name; browser : docbrowse shipped - with cameleon and ocamlbrowser - shipped with &ocaml-name; itself. The first one, need specific - &ocamldoc; generated documentation. The second one enables - the user to browse directly the prototype of each function shipped in the cmi gives - to the application. - - - - You can generate &ocamldoc; specific documentation by using - the of this application. By using this, you dump the - intermediary representation of the document that will be generated by ocamldoc. - This can be used to generate HTML documentation and manpages, by reloading this - file ( using ). - - - - As of today, there is no way to post-process &ocamldoc; - specific documentation. A &debian-name; package is under construction to do this - task. It will be referred as &ocamldoc-base;. - - -
- -
- Path for all &ocaml-name; component - - - Ocaml will search library in two different location, referred to - as local which hold user installed library and as - core in which packaged modules stood. - - -
- Library paths - - - By default, &ocaml-name; will look for modules in this order : - - - local - /usr/local/lib/ocaml/&ocaml-version;/ - - - core - /usr/lib/ocaml/&ocaml-version;/ - - - - - - When installing a library, packagers should use a subdirectory of the preceding - set of path. Subdirectory name is not mandatory. - - - - If upstream developpers use already a subdirectory of the &ocaml-name; - standard library path, this path should be preserved in the &debian-name; - package, but made relative to the standard library path of the &ocaml-pkg;. - Before using the provided subdirectory, packagers should check if there is - no subdirectory name clash with other &ocaml-name; library. - - - - If upstream developpers don't use this scheme, packagers are encouraged not - to install this library in the standard library directory. They should create - at least a subdirectory per source package ( in order to avoid library - name clash ). Packagers should also consider to do a larger separation by - creating a subdirectory per binary package ( in order to avoid META name - clash ). - - - - A suggested rule to choose name for this subdirectory is to use either the package - name provided by the META of the upstream, or the name of the library itself. - - -
- -
- <filename>META</filename> - - - META distribution is the best way to make more - easy specific library subdirectory oragnization. Even, if user building - a simple executable should only need one library, and don't want to - bother himself by using &ocamlfind;, this same user will find one day - that using &ocamlfind; permit him to compile from anywhere. - - - - Since we distribute META, all devel library - should suggest the use of &ocamlfind;. So a Suggest: - should be set to &ocamlfind-pkg;. - - - - By default, &ocamlfind; will look for META in this order : - - - local - /usr/local/lib/ocaml/&ocaml-version;/META/ - /usr/local/lib/ocaml/&ocaml-version;/package/ - - - core - /usr/lib/ocaml/&ocaml-version;/META/ - /usr/lib/ocaml/&ocaml-version;/package/ - - - - - - The naming scheme of META is pretty simple : - - If META is placed in the subdirectory - of the package, it should be called META. If - you don't call it this way, it won't be recognized by &ocamlfind;. - - If META is placed in - /usr/lib/ocaml/&ocaml-version;/META/, it should - be called META.package. In order to avoid - name clash, it should be specialized to the binary package it is shipped - from, otherwise package should be the package source. - - - - - - If upstream doesn't provide a META, packager are encouraged - to create one. It should be placed in the - /usr/lib/ocaml/&ocaml-version;/META/. META - should be sent to upstream authors, in order to have it in the next version of - the upstream source. - - -
- - -
- &ocamldoc; specific generated documentation - - - Even if this way of producing documentation is not mandatory, packagers are - encouraged to use it, in order to ship lighter documentation, which could - be processed by &ocaml-name; tools. - - - - By default, &ocamldoc-base; will look for *.odoc in this order : - - - local - /usr/local/share/ocamldoc/&ocaml-version;/ - - - core - /usr/share/ocamldoc/&ocaml-version;/ - - - - - - As for library, the naming scheme of the *.odoc should be - at least the name of the source package from which the documentation was - generated. If a source package is split in many binary package and the - documentation comes only in one *.odoc, packagers are - encouraged to create a separate package and to Suggest: it - in each binary package which he described. If this could not be met, it is at - least a good practice to Suggest: the package containing - the documentation. - The packager should consider to ship one *.odoc per - library package. - - - - By doing this, &ocaml-force; is trying to build a clear way of distributing - documentation. It should help user to find and exploit the documentation - coming from the source. Generating &ocamldoc; documentation is not so hard, - and should take a one line call. Commenting the code in order to generate - fully functional documentation is however an upstream task. Packager are encouraged - to patch Makefile in order to have a target - odoc, generating this documentation and to contact upstream - author to have a well commented source. - -
- -
- - Actually, &camlp4; extensions are stored in - /usr/lib/ocaml/&ocaml-version;/camlp4/. In order to do something - cleaner, &ocaml-force; propose to put this files in their own directory, even in their - own package. It is not mandatory, but it could ease a lot, the user of camlp4, by avoiding - name clash. - - - - You just have to consider &camlp4; file just as standard library, except that you - prefix them with -syntax. For example : the syntax - extension coming with libokey-ocaml-dev should be stored - in /usr/lib/ocaml/&ocaml-version;/okey-syntax/, the package - containing it should be called libokey-syntax-ocaml-dev. - - - - - It is recommended to use META to specify how to handle this - extension. - - - - All definition is taken from previous text considering syntax extension as a standalone - library. - - -
-
- - diff --git a/chapter-progpack.xml b/chapter-progpack.xml index e69de29b..2a671e27 100644 --- a/chapter-progpack.xml +++ b/chapter-progpack.xml @@ -0,0 +1,6 @@ +
+ Packaging OCaml prgrams + + blah + +
diff --git a/legal.xml b/legal.xml index e2ac3680..a1d3f782 100644 --- a/legal.xml +++ b/legal.xml @@ -1,29 +1,29 @@ - - 20022003 - Sven LUTHER, Stefano ZACCHIROLI and Sylvain LE GALL - + + 20022003200420052006 + Sylvain LE GALL, Sven LUTHER, Samuel MIMRAM and Stefano ZACCHIROLI + + - This manual is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License - as published by the Free Software Foundation; either version - 2 of the License, or (at your option) any later version. + This manual is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. - This is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See - the GNU General Public License for more details. + This is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See + the GNU General Public License for more details. - A copy of the GNU General Public License is available as - /usr/share/common-licenses/GPL in the Debian GNU/Linux - distribution or on the World Wide Web at - The GNU Public Licence. + A copy of the GNU General Public License is available as + /usr/share/common-licenses/GPL in the Debian GNU/Linux + distribution or on the World Wide Web at + The GNU Public Licence. - You can also obtain it by writing to the - Free Software Foundation, Inc., 59 Temple Place - Suite 330, - Boston, MA 02111-1307, USA. + You can also obtain it by writing to the + Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. - - + diff --git a/ocaml_packaging_policy.xml b/ocaml_packaging_policy.xml index 4c76b64b..f94a7d30 100644 --- a/ocaml_packaging_policy.xml +++ b/ocaml_packaging_policy.xml @@ -1,67 +1,61 @@ - - - ocaml"> - ocaml-&ocaml-version;-&ocaml-compat;"> - ocaml-base-&ocaml-version;-&ocaml-compat;"> - ocaml-findlib"> - ocamldoc-base"> - OCaml"> - - ocamlc"> - ocamlopt"> - ocamldoc"> - ocamlfind"> - camlp4"> - - - - - - - - - + + +ocaml"> +ocaml-&ocaml-version;"> +ocaml-base-&ocaml-version;"> +ocaml-findlib"> +ocamldoc-base"> +OCaml"> + +ocamlc"> +ocamlopt"> +ocamldoc"> +ocamlfind"> +camlp4"> + + + + + + + + + + ]> -
- - &debian-name; &ocaml-name; Packaging Policy - For Objective Caml version &ocaml-version; - Revision 0.1 - - &authors; - &legal; - + + + &debian-name; &ocaml-name; Packaging Policy for OCaml &ocaml-version; + Revision 0.7 + &authors; + &legal; + - - &ocaml-name; Packaging - &chapter-ocaml; - + + Generalities about &ocaml-name; packages in Debian + &chapter-generalities; + - - Locally installed library - &chapter-liblocal; - + + Packaging OCaml Programs + &chapter-progpack; + - - Packaged library - &chapter-libpack; - + + Packaging OCaml libraries + &chapter-libpack; + - - Packaged program - &chapter-progpack; - + + Managing version transition + &appendix-transition; + - - Managing version transition - &appendix-transition; - - - - &ocaml-force; resources - &appendix-resources; - -
+ + &ocaml-force; resources + &appendix-resources; + +