cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From upayav...@apache.org
Subject svn commit: r167906 - in /cocoon/whiteboard/doc-repos/global/src/content/xdocs: OLD-committer/ OLD-committers/ OLD-versioning/ committer-tips/ committer-tips/meta.xml community/content_en.html community/content_en.xml site.xml versioning/ versioning/comments_en.xml versioning/content_en.html versioning/meta.xml
Date Tue, 03 May 2005 14:05:39 GMT
Author: upayavira
Date: Tue May  3 07:05:38 2005
New Revision: 167906

URL: http://svn.apache.org/viewcvs?rev=167906&view=rev
Log:
Moving a few pages over.


Added:
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/
      - copied from r164999, cocoon/whiteboard/doc-repos/global/src/content/xdocs/OLD-committer/
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.html
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/
      - copied from r164999, cocoon/whiteboard/doc-repos/global/src/content/xdocs/OLD-versioning/
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/comments_en.xml
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/content_en.html
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/meta.xml
Removed:
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/OLD-committer/
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/OLD-committers/
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/OLD-versioning/
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.xml
Modified:
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/meta.xml
    cocoon/whiteboard/doc-repos/global/src/content/xdocs/site.xml

Modified: cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/meta.xml
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/meta.xml?rev=167906&r1=164999&r2=167906&view=diff
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/meta.xml (original)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/committer-tips/meta.xml Tue May 
3 07:05:38 2005
@@ -3,7 +3,4 @@
   <authors>
     <author contact="http://cocoon.apache.org">Cocoon Community</author>
   </authors>
-  <legacy>
-    <original-filename>community/committer.html</original-filename>
-  </legacy>
 </meta>

Added: cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.html
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.html?rev=167906&view=auto
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.html (added)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/community/content_en.html Tue May
 3 07:05:38 2005
@@ -0,0 +1,175 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>The Cocoon Community</title>
+<link href="http://purl.org/DC/elements/1.0/" rel="schema.DC">
+</head>
+<body>
+
+ 
+<h1>Who we are</h1>
+  
+  
+<p>
+    The Apache Cocoon Project operates on a meritocracy: the more you do, the more 
+    responsibility you will obtain. This page lists all of the people who have 
+    gone the extra mile and are Committers. If you would like to get involved, 
+    the first step is to join the mailing lists. 
+  </p>
+
+  
+<p>
+    We ask that you please do not send us emails privately asking for support. 
+    We are non-paid volunteers who help out with the project and we do not 
+    necessarily have the time or energy to help people on an individual basis. 
+    Instead, we have setup mailing lists which often contain hundreds of 
+    individuals who will help answer detailed requests for help. The benefit of 
+    using mailing lists over private communication is that it is a shared 
+    resource where others can also learn from common mistakes and as a 
+    community we all grow together. 
+  </p>
+  
+  
+<h1>The Community</h1>
+  
+    
+<p>
+    This list contains all past and present committers on the various Cocoon projects
+    in strict alphabetical order. For details of contributors to a specific version of
+    Cocoon, see the relevant version pages 
+    (e.g. <a class="external" href="http://cocoon.apache.org/2.2/who.html">2.2</a>).
+    </p>
+    
+<ul>
+      
+<li>Zvi Avraham (zvia.at.apache.org)</li>
+      
+<li>Donald Ball (balld.at.apache.org)</li>
+      
+<li>Nicola Ken Barozzi (nicolaken.at.apache.org)</li>
+      
+<li>Brian Behlendorf (brian.at.apache.org)</li>
+      
+<li>Ross Burton (rossb.at.apache.org)</li>
+      
+<li>Mark Butler (butlermh.at.apache.org)</li>
+      
+<li>Guido Casper (gcasper.at.apache.org)</li>
+      
+<li>Ugo Cei (ugo.at.apache.org)</li>
+      
+<li>Steven Coffman (gears.at.apache.org)</li>
+      
+<li>Tony Collen (tony.at.apache.org)</li>
+      
+<li>Marcus Crafter (crafterm.at.apache.org)</li>
+      
+<li>David Crossley (crossley.at.apache.org)</li>
+      
+<li>Torsten Curdt (tcurdt.at.apache.org)</li>
+      
+<li>Bertrand Delacr&eacute;taz (bdelacretaz.at.apache.org)</li>
+      
+<li>Peter Donald (donaldp.at.apache.org)</li>
+      
+<li>Bruno Dumon (bruno.at.apache.org)</li>
+      
+<li>Daniel Fagerstr&ouml;m (danielf.at.apache.org)</li>
+      
+<li>Gerhard Froehlich (froehlich.at.apache.org)</li>
+      
+<li>Pier Fumagalli (pier.at.apache.org)</li>
+      
+<li>Antonio Gallardo (antonio.at.apache.org)</li>
+      
+<li>Leszek Gawron (lgawron.at.apache.org)</li>
+      
+<li>Ralph Goers (rgoers.at.apache.org)</li>
+      
+<li>Robin Green (greenrd.at.apache.org)</li>
+      
+<li>Vadim Gritsenko (vgritsenko.at.apache.org)</li>
+      
+<li>Christian Haul (haul.at.apache.org)</li>
+      
+<li>J&ouml;rg Heinicke (joerg.at.apache.org)</li>
+      
+<li>Unico Hommes (unico.at.apache.org)</li>
+      
+<li>Geoff Howard (ghoward.at.apache.org)</li>
+      
+<li>Bernhard Huber (huber.at.apache.org)</li>
+      
+<li>Ivelin Ivanov (ivelin.at.apache.org)</li>
+      
+<li>Matthew Langham (mlangham.at.apache.org)</li>
+      
+<li>Tim Larson (tim.at.apache.org)</li>
+      
+<li>Ben Laurie (ben.at.apache.org)</li>
+      
+<li>Berin Loritsch (bloritsch.at.apache.org)</li>
+      
+<li>Martin Man (mman.at.apache.org)</li>
+      
+<li>Stefano Mazzocchi (stefano.at.apache.org)</li>
+      
+<li>Brett McLaughlin (bmclaugh.at.apache.org)</li>
+      
+<li>Michael Melhem (michaelm.at.apache.org)</li>
+      
+<li>Stephan Michels (stephan.at.apache.org)</li>
+      
+<li>John Morrison (morrijr.at.apache.org)</li>
+
+<li>Alfred Nathaniel (anathaniel.at.apache.org)</li>
+      
+<li>Steven Noels (stevenn.at.apache.org)</li>
+      
+<li>Christopher Oliver (coliver.at.apache.org)</li>
+      
+<li>Giacomo Pati (giacomo.at.apache.org)</li>
+      
+<li>Konstantin Piroumian (kpiroumian.at.apache.org)</li>
+      
+<li>Marc Portier (mpo.at.apache.org)</li>
+      
+<li>Reinhard P&ouml;tz(reinhard.at.apache.org)</li>
+      
+<li>Ovidiu Predescu (ovidiu.at.apache.org)</li>
+      
+<li>Jeremy Quinn (jeremy.at.apache.org)</li>
+      
+<li>Gianugo Rabellino (gianugo.at.apache.org)</li>
+      
+<li>Ricardo Rocha (ricardo.at.apache.org)</li>
+      
+<li>Peter Royal (proyal.at.apache.org)</li>
+      
+<li>Sam Ruby (rubys.at.apache.org)</li>
+      
+<li>Paul Russell (prussell.at.apache.org)</li>
+      
+<li>Sebastien Sahuc (ssahuc.at.apache.org)</li>
+      
+<li>Andrew Savory (asavory.at.apache.org)</li>
+      
+<li>Diana Shannon (shannon.at.apache.org)</li>
+      
+<li>Davanum Srinivas (dims.at.apache.org)</li>
+      
+<li>Jeff Turner (jefft.at.apache.org)</li>
+      
+<li>Upayavira (upayavira.at.apache.org)</li>
+      
+<li>Sylvain Wallez (sylvain.at.apache.org)</li>
+      
+<li>Carsten Ziegeler (cziegeler.at.apache.org)</li>
+    
+</ul>
+ 
+
+
+</body>
+</html>

Modified: cocoon/whiteboard/doc-repos/global/src/content/xdocs/site.xml
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/site.xml?rev=167906&r1=167905&r2=167906&view=diff
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/site.xml (original)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/site.xml Tue May  3 07:05:38 2005
@@ -41,18 +41,18 @@
   
   <docs label="Community" tab="community">
     <doc label="Who we are?" href="community.html"/>  
-    <doc label="Contributing"/>
-    <doc label="Committer Tips"/><!-- content from developer info page to be merged
into this page or subordinate pages -->
-    <doc label="Mailing Lists"/>
-    <doc label="Mail Archives"/> 
+    <doc label="Contributing" href="contributing.html"/>
+    <doc label="Committer Tips" href="committer-tips.html"/><!-- content from developer
info page to be merged into this page or subordinate pages -->
+    <doc label="Mailing Lists" href="mailing-lists.html"/>
+    <doc label="Mail Archives" href="mail-archives.html"/> 
     <doc label="Collaboration Tools">
-      <doc label="Subversion"/>
-      <doc label="Bugzilla"/>
-      <doc label="Wiki"/>
-      <doc label="IRC channel"/>
+      <doc label="Subversion" href="subversion.html"/>
+      <doc label="Bugzilla" href="bugzilla.html"/>
+      <doc label="Wiki" href="http://wiki.apache.org/cocoon/"/>
+      <doc label="IRC channel" href="irc.html"/>
     </doc>
-    <doc label="Events"/><!-- this page includes an 'informal meetings' link to
a wiki page, as well as links to GetTogether, ApacheCon, etc -->
-    <doc label="Versioning Scheme"/>
+    <doc label="Events" href="events.html"/><!-- this page includes an 'informal
meetings' link to a wiki page, as well as links to GetTogether, ApacheCon, etc -->
+    <doc label="Versioning Scheme" href="versioning.html"/>
   </docs>
   
   <!--

Added: cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/comments_en.xml
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/comments_en.xml?rev=167906&view=auto
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/comments_en.xml (added)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/comments_en.xml Tue May
 3 07:05:38 2005
@@ -0,0 +1,6 @@
+<?xml version="1.0"?>
+<comments>
+  <comment name="Reinhard Poetz" by="http://www.poetz.cc" subject="the first comment">
+    my first comment
+  </comment>
+</comments>

Added: cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/content_en.html
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/content_en.html?rev=167906&view=auto
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/content_en.html (added)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/content_en.html Tue May
 3 07:05:38 2005
@@ -0,0 +1,364 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+<head>
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<title>The Apache Cocoon Versioning Manifesto - DRAFT</title>
+<link href="http://purl.org/DC/elements/1.0/" rel="schema.DC">
+</head>
+<body>
+    
+<div class="warning">DRAFT INITIAL VERSION</div>
+
+    
+<p>
+      This document covers how the Cocoon project is versioned. 
+      Since Cocoon is a framework, it is very important to define a stable API 
+      for users and developers. However, we also need to move Cocoon forward, 
+      technologically. To balance these two needs, a strict policy of versioning 
+      is required, which users can rely upon to understand the limitations, 
+      restrictions, and the changes that can occur from one release to the next.
+    </p>
+
+    
+<h1>Basics</h1>
+      
+      
+<p>
+        Versions are denoted using a standard triplet of integers: 
+      </p>
+      
+<p>
+        MAJOR.MINOR.PATCH. 
+      </p>
+      
+<p>
+        The basic intent is that MAJOR versions are incompatible, large-scale 
+        upgrades of the API. MINOR versions retain usage and extension compatibility 
+        with older minor versions, and changes in the PATCH level are perfectly 
+        compatible, forwards and backwards.
+      </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 
+        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.
+      </p>
+      
+<p>
+        A developer codes Java and provides additional functionality for the user, 
+        so a developer extends Cocoon.
+      </p>
+      
+<p>
+        Therefore we distinguish between usage compatibility (user API) and 
+        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 safer to compile your own application 
+        code (if any) using the version of Cocoon that your application runs on.
+      </p>
+      
+<p>
+        There are several reasons why recompilation is recommended. We strongly
+        advise to compile Cocoon (or any other Java application) with the same
+        JDK that is later used in production.
+      </p>
+      
+<ul>
+        
+<li>
+          Ensures that you have reliable operating environment. For example if
+          you compile a Java application with JDK 1.4 in JDK 1.3 compatible mode
+          it still can happen that your application doesn't run properly with JDK 1.3!
+          This is not Cocoon specific!
+        </li>
+        
+<li>
+          Allows you to easily configure which parts you want. The selection of
+          wanted blocks is currently evaluated at build time, so if you want
+          to have an additional block/remove a block in your Cocoon installation,
+          you have to rebuild Cocoon.
+        </li>
+        
+<li>
+          You will get warned about deprecated parts of the API.        
+        </li>
+      
+</ul>
+    
+    
+<h1>Usage Compatibility</h1>
+      
+      
+<p>
+        
+<em>Usage</em> compatibility guarantees that an application written by 
+        a Cocoon user is compatible. All files developed by a typical Cocoon 
+        user like xml files, sitemaps, stylesheets (elements and namespace declarations)

+        keep on being picked up by the machinery and are dealt with correctly 
+        (sitemap semantics, generator/transformer-picked up elements, config 
+        file entries...). 
+      </p>
+      
+<p>
+        In fact this should cover everything (including flow script) but except 
+        your own Java code.
+      </p>
+      
+<p>
+        Applications that write against a particular version will remain usage 
+        compatible against later versions, until the major number changes.
+      </p>
+      
+<p>
+        Writing an application against a version means that this application 
+        does not use any deprecated API of that version. Therefore minor version 
+        changes are only usage compatible from one minor version to the direct 
+        following one. For example 2.2 is usage compatible to 2.1. But 2.3 is not 
+        necessarily usage compatible to 2.1, although it is usage compatible 
+        to 2.2. As long as you don't use deprecated API (and the API you rely 
+        on does not get deprecated), your application is usage compatible across 
+        all minor versions.
+      </p>
+      
+<p>
+        Example: 
+      </p>
+      
+<ul>
+        
+<li>a feature is introduced in 2.0 and used by the application.</li>
+        
+<li>it is deprecated in 2.2</li>
+        
+<li>it will be removed in 2.3</li>
+      
+</ul>
+      
+<p>
+        If the time inbetween two minor releases is very short, then it might 
+        happen that deprecated parts will be kept in the following minor release 
+        and are removed in a follow-up minor release. This is in order to ensure 
+        that users have time to update their applications if they use the deprecated 
+        parts.
+      </p>
+      
+<p>
+        However, if an application uses an API which has become available in a 
+        particular minor version, it (obviously) will no longer operate against 
+        previous minor versions.
+      </p>
+    
+    
+<h1>Extension Compatibility</h1>
+      
+      
+<p>
+        
+<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>
+        Applications that write against a particular version will remain extension 
+        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 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>
+      
+<p>
+        If an interface/class changes in an incompatible way between minor 
+        version changes, the Cocoon documentation will contain a detailed update 
+        guide that contains a solution for every incompatible change. So following 
+        this guide should make the update smoothly.
+      </p>
+    
+    
+<h1>Deprecation and Exceptions</h1>
+      
+      
+<p>
+        To continue the Cocoon development and to keep up with the innovations,
+        parts of Cocoon might get deprecated; this includes parts of the user
+        API and also parts of the developer API.
+      </p>
+      
+<p>
+        If a part of the user API is deprecated, this will be flagged through 
+        run-time warnings that appear in the logs but remain supported. This
+        indicates that an upcoming minor (or major) release will no longer 
+        support this.
+      </p>
+      
+<p>
+        If a part of the developer API is deprecated it will be removed with 
+        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 from updating the application. 
+      </p>
+      
+<p>
+        For developers there is one exception to this rule: private API. Cocoon
+        has some internal classes and interfaces that are not meant to be used
+        by a Cocoon developer (someone extending Cocoon). These pieces of
+        Java code are clearly marked in the Javadocs and should not be used.
+        They might change even between a patch version change in an incompatible
+        way without providing a workaround!      
+      </p>
+    
+    
+<h1>Blocks and Block Stability</h1>
+      
+      
+<p>
+        Cocoon currently allows optional functionality to be included or excluded 
+        using a simple system called blocks, in which the functionality is included 
+        or excluded at compile time.
+      </p>
+      
+<p>
+        [NB. This is a precursor to a more complete block system which is 
+        currently under development.]
+      </p>
+      
+<p>
+        A block can have one of three statuses: unstable, stable or deprecated. 
+        An unstable block has an API that can change without notice. A stable block 
+        is subject to the same versioning process as described in this document. 
+        Similarly, when the entire functionality of a block is deprecated, it will 
+        be handled in the same way as any other deprecated code within Cocoon.
+      </p>
+    
+    
+<h1>External Libraries</h1>
+      
+      
+<p>
+        Cocoon uses a set of external libraries (like for example Avalon, 
+		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 
+        changes inbetween two Cocoon versions and therefore your application 
+        does not work properly anymore (or even does not compile anymore).
+        Unfortunately, this issue is out of the scope of Cocoon.
+      </p>
+      
+<p>
+        The documentation of Cocoon contains a list of the libraries and the
+        version changes between libraries from one Cocoon release to another.
+      </p>
+    
+    
+<h1>Exsamples</h1>
+      
+      
+<p>
+        Here are some examples to demonstrate the compatibility:
+      </p>
+<!-- TODO: Change the format: -->
+      
+<pre class="code">
+Original Version    New Version    Usage Compatible    Extension Compatible
+2.2.3                  2.2.4          Yes                      Yes
+2.2.3                  2.3.1          Yes                      No
+2.2.3                  3.0.0          No                       No
+      </pre>
+      
+<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 
+        used by the application.
+      </p>
+    
+    
+<h1>Versioning and Repositories</h1>
+      
+      
+<p>
+        Cocoon is very innovative and new features are added very frequently. This
+        results in new functionality that justify a minor version change on its own.
+        In addition, to move Cocoon forward technologically, some features have
+        to be removed/deprecated which of course results in a minor version change
+        as well.
+      </p>
+      
+<p>
+        So, Cocoon will potentially release several versions with minor version
+        changes in a year and only a few patch releases. Of course, if a patch
+        release is required, for example if a potential security issue is found
+        etc., the patch release will be made available asap.
+      </p>
+      
+<p>
+        This high innovention has - at least in theory - the price of maintaining
+        several branches at once in order to be able to apply patches to older
+        versions. 
+      </p>
+      
+<p>
+        To reduce this to a minimum, Cocoon uses one repository per major version.
+        The HEAD of the repository always contains the latest version. If a new
+        minor release is required, the version in the repository is directly changed
+        to this minor version (e.g. from 2.1.4 to 2.2). The current state is
+        tagged and if the need for a 2.1.5 release arises, a branch is created.
+      </p>
+      
+<p>
+        However, due to the compatibility rules explained above, there should only
+        be a reason for a patch version if major problems occur (like security
+        issues). In any other case, the Cocoon community expects the applications
+        to migrate to the new minor version release which should be fairly simple.
+      </p>
+      
+<p>
+        In addition Cocoon has a sandbox repository to test new features.
+      </p>
+    
+    
+<h1>Reality</h1>
+      
+      
+<p>
+        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 good intentions. 
+        In case anyone finds clear violation or signs of potential problems of these 
+        good intentions, please report those 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
+        application from one Cocoon to another one will be very time consuming.
+        Or that we are acting arbitrarily in deprecating stuff here and there.
+      </p>
+      
+<p>
+        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 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
+        as they want.
+      </p>
+    
+  
+</body>
+</html>

Added: cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/meta.xml
URL: http://svn.apache.org/viewcvs/cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/meta.xml?rev=167906&view=auto
==============================================================================
--- cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/meta.xml (added)
+++ cocoon/whiteboard/doc-repos/global/src/content/xdocs/versioning/meta.xml Tue May  3 07:05:38
2005
@@ -0,0 +1,6 @@
+<?xml version="1.0"?>
+<meta>
+  <authors>
+    <author contact="http://www.poetz.cc">Reinhard Poetz</author>
+  </authors>
+</meta>



Mime
View raw message