You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cr...@apache.org on 2004/04/23 18:08:24 UTC
cvs commit: cocoon-site/src/documentation/content/xdocs versioning.xml
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 dev@cocoon.apache.org 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>