cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject cvs commit: cocoon-site/src/documentation/content/xdocs versioning.xml
Date Fri, 23 Apr 2004 16:08:24 GMT
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>
  
  
  

Mime
View raw message