crossley 2004/04/23 09:08:24
Modified: src/documentation/content/xdocs versioning.xml
Log:
Text tweaks.
Simple source format for table.
Fix xml validation.
Revision Changes Path
1.2 +21 -26
cocoon-site/src/documentation/content/xdocs/versioning.xml
Index: versioning.xml
===================================================================
RCS file:
/home/cvs/cocoon-site/src/documentation/content/xdocs/versioning.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- versioning.xml 23 Apr 2004 08:42:41 -0000 1.1
+++ versioning.xml 23 Apr 2004 16:08:24 -0000 1.2
@@ -34,7 +34,7 @@
</p>
<p>
Following the main design principle of Cocoon, the pyramid of
contracts,
- we distinguish between users and developers of Cocoon.A very rough
distinction
+ we distinguish between users and developers of Cocoon. A very rough
distinction
between them is that a user writes the application using Cocoon
without
coding Java. There is one exception to this rule: flow script - the
java
script is also written by the user.
@@ -48,7 +48,7 @@
extension compatibility (developer API). Both compatibility levels
cover
some kind of "source" compatibility. Cocoon does not provide binary
compatibility. But as Cocoon is distributed as a source release that
- you have to compile anyway, it's saver to compile your own
application
+ you have to compile anyway, it's safer to compile your own
application
code (if any) using the version of Cocoon that your application runs
on.
</p>
<p>
@@ -70,9 +70,9 @@
you have to rebuild Cocoon.
</li>
<li>
- You'll get warned of deprecated parts of the API.
+ You will get warned about deprecated parts of the API.
</li>
- </p>
+ </ul>
</section>
<section id="usage-compatibility">
<title>Usage Compatibility</title>
@@ -86,7 +86,7 @@
</p>
<p>
In fact this should cover everything (including flow script) but
except
- own Java code.
+ your own Java code.
</p>
<p>
Applications that write against a particular version will remain
usage
@@ -126,8 +126,8 @@
<section id="extension-compatibility">
<title>Extension Compatibility</title>
<p>
- <em>extension</em> compatibility guarantees that own extensions to
what
- Cocoon provides (own Java classes that interface directly with API
in the
+ <em>extension</em> compatibility guarantees that your own extensions
to what
+ Cocoon provides (your Java classes that interface directly with API
in the
Cocoon distribution) compile and operate.
</p>
<p>
@@ -135,7 +135,7 @@
compatible against later versions until the major or the minor
number
changes (Please note the difference to the usage compatibility).
However,
the Cocoon developers take care that even if the minor number
changes,
- most of the own code still works and operates properly. Incompatible
+ most of the their own code still works and operates properly.
Incompatible
changes between minor versions are kept to a minimum. Frequent new
releases
of Cocoon ensure that developers have a smooth transition path.
</p>
@@ -164,7 +164,7 @@
the next major, minor or patch release. However, the need for
removing
deprecated stuff between two patch releases is really very rare and
will only happen if the cost of keeping it is much higher than the
- cost that might occur for updating the application.
+ cost that might occur from updating the application.
</p>
<p>
For developers there is one exception to this rule: private API.
Cocoon
@@ -198,12 +198,13 @@
<title>External Libraries</title>
<p>
Cocoon uses a set of external libraries (like for example Avalon,
- Xalan or Xerces). Inbetween any release, even patch releases,
+ Xalan or Xerces). Between any release, even patch releases,
the versions of the external libraries might be updated to any
version.
Cocoon only updates external libraries if there are good reasons
for it, like important bug fixes or new features that will be
used by the new Cocoon version.
</p>
+<!-- TODO: Should we mention the testing framework? -->
<p>
Therefore if your application is written against a special API of an
external library it might be that this API of the external library
@@ -222,18 +223,12 @@
Here are some examples to demonstrate the compatibility:
</p>
<!-- TODO: Change the format: -->
- <p>
- Original Version New Version Usage Compatible Extension
Compatible
- </p>
- <p>
+ <source>
+Original Version New Version Usage Compatible Extension Compatible
2.2.3 2.2.4 Yes Yes
- </p>
- <p>
2.2.3 2.3.1 Yes No
- </p>
- <p>
2.2.3 3.0.0 No No
- </p>
+ </source>
<p>
Note: while some of the cells say "no", it is possible that the
versions
may be compatible, depending very precisely upon the particular APIs
@@ -280,13 +275,13 @@
<section id="reality">
<title>Realitiy</title>
<p>
- The above expresses the intentions of the cocoon community to
support a
+ The above expresses the intentions of the Cocoon community to
support a
release management contract to all the users of the framework.
However
reality observes that the path to hell is paved with goood
intentions.
In case anyone finds clear violation or signs of potential problems
of these
- good intentions he/she should report those to [email protected]
in order
- to let proper action be taken (which might be reverting some changes
and/or
- assigning a different version number).
+ good intentions, please report those to to the mailing lists or issue
+ tracker so that proper action can be taken (which might be reverting
+ some changes and/or assigning a different version number).
</p>
<p>
If you have read this, you might get the impression that updating
your
@@ -297,11 +292,11 @@
Of course this is not the case :) Before we introduce new features,
new
API we discuss this in great detail, so this should reduce potential
errors in the design to a minimum. In addition, deprecating stuff is
- also handled with great care. So, in the end, this guide establish
+ also handled with great care. So, in the end, this guide establishes
rules that detail how we handle such rare situations. It is not a
free ticket for the Cocoon developers to deprecate/change/remove
stuff
- like they want.
+ as they want.
</p>
</section>
</body>
-</document>
\ No newline at end of file
+</document>
