You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by jo...@apache.org on 2001/05/04 03:09:24 UTC
cvs commit: jakarta-turbine/xdocs deprecation.xml
jon 01/05/03 18:09:24
Added: docs deprecation.html
xdocs deprecation.xml
Log:
added a deprecation policy.
this commit is dedicated to Sam Ruby.
biteme.
Revision Changes Path
1.1 jakarta-turbine/docs/deprecation.html
Index: deprecation.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- Content Stylesheet for Site -->
<!-- start the processing -->
<!-- ====================================================================== -->
<!-- Main Page Section -->
<!-- ====================================================================== -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<meta name="author" value="Jon S. Stevens">
<meta name="email" value="jon@latchkey.com">
<title>Turbine - Turbine Deprecation Policy</title>
</head>
<body bgcolor="#ffffff" text="#000000" link="#525D76">
<table border="0" width="100%" cellspacing="0">
<!-- TOP IMAGE -->
<tr>
<td align="left">
<a href="http://jakarta.apache.org"><img src="http://jakarta.apache.org/images/jakarta-logo.gif" border="0"/></a>
</td>
<td align="right">
<a href="http://jakarta.apache.org/turbine/"><img src="./images/logo.gif" alt="Turbine" border="0"/></a>
</td>
</tr>
</table>
<table border="0" width="100%" cellspacing="4">
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr>
<!-- LEFT SIDE NAVIGATION -->
<td valign="top" nowrap="true">
<p><strong>Essentials</strong></p>
<ul>
<li> <a href="./index.html">Overview</a>
</li>
<li> <a href="./features.html">Features</a>
</li>
<li> <a href="./fsd.html">Specification</a>
</li>
<li> <a href="./project-map.html">Project map</a>
</li>
<li> <a href="./install.html">Installation</a>
</li>
<li> <a href="./getting-started.html">Getting Started</a>
</li>
<li> <a href="./changes.html">Changes</a>
</li>
<li> <a href="./other-docs.html">Other Documentation</a>
</li>
</ul>
<p><strong>Models</strong></p>
<ul>
<li> <a href="./pullmodel.html">Pull MVC Model</a>
</li>
<li> <a href="./model2+1.html">Model 2+1</a>
</li>
<li> <a href="./j2ee-integration.html">J2EE Integration</a>
</li>
</ul>
<p><strong>Get Involved</strong></p>
<ul>
<li> <a href="./turbine-documentation-project.html">Turbine Documentation</a>
</li>
<li> <a href="./code-standards.html">Coding Spec</a>
</li>
<li> <a href="./contributors.html">Contributors</a>
</li>
<li> <a href="./branches.html">CVS Branches</a>
</li>
<li> <a href="http://jakarta.apache.org/site/cvsindex.html">CVS Repos</a>
</li>
<li> <a href="./faq.html">FAQ</a>
</li>
<li> <a href="./license.html">License</a>
</li>
<li> <a href="http://jakarta.apache.org/site/mail.html">Mailing Lists</a>
</li>
<li> <a href="./powered.html">Powered by Turbine</a>
</li>
<li> <a href="./todo.html">Todo</a>
</li>
<li> <a href="./active-developers.html">Active Developers</a>
</li>
<li> <a href="./proposals.html">Proposals</a>
</li>
</ul>
<p><strong>Documentation</strong></p>
<ul>
<li> <a href="./action-event.html">Action Events</a>
</li>
<li> <a href="./services.html">Services</a>
</li>
<li> <a href="./security.html">Turbine and Security</a>
</li>
<li> <a href="./python.html">Turbine and Python</a>
</li>
<li> <a href="./jsp-configuration.html">Turbine and JSP</a>
</li>
<li> <a href="./velocity-site.html">Velocity Site</a>
</li>
<li> <a href="./context-howto.html">Velocity Context</a>
</li>
<li> <a href="./webmacro-site.html">Webmacro Site</a>
</li>
</ul>
<p><strong>Database</strong></p>
<ul>
<li> <a href="./peers.html">Peers</a>
</li>
<li> <a href="./advpeers.html">Advanced Peers</a>
</li>
<li> <a href="./advcriteria.html">Advanced Criteria</a>
</li>
<li> <a href="./torque.html">Torque</a>
</li>
<li> <a href="./turbine-schema.html">Core Schema</a>
</li>
<li> <a href="./db-adapters.html">DB Adapters</a>
</li>
<li> <a href="./postgres-howto.html">Postgres Howto</a>
</li>
<li> <a href="./oracle-howto.html">Oracle 8i Howto</a>
</li>
<li> <a href="./sybase-howto.html">Sybase Howto</a>
</li>
</ul>
</td>
<td align="left" valign="top">
<table border="0" cellspacing="0" cellpadding="2" width="100%">
<tr><td bgcolor="#525D76">
<font color="#ffffff" face="arial,helvetica,sanserif">
<a name="Turbine Deprecation Policy"><strong>Turbine Deprecation Policy</strong></a>
</font>
</td></tr>
<tr><td>
<blockquote>
<p>
In order for people to be comfortable with development of code based on
Turbine and not have to constantly worry about the rug being pulled out
from underneath them, we have instituted the following policy. Our goal
is to take this matter as an extremely serious practice.
</p>
<p>
<ol>
<li>
<strong>ALL</strong> existing class and method modification needs to go
through a deprecation phase. We realize that this may make some of the
API code look a bit ugly when you look at the source code, but this is a
MUST have. It is recommend that developers who deprecate methods move
them to the bottom of the .java file.
</li>
<li>
The amount of time between deprecation and removal must be at least one
release of Turbine. In other words, we can deprecate something in 2.1
and remove it in the release of 2.1.1. The amount of time between 2.1
and 2.1.1 could be measured in days, not months. The reason why we do
not feel that time is of importance is because 6 months may not be a
long enough time for a project to keep up and 2 weeks might be fine for
another project. By focusing on deprecation through releases, people can
choose to code against a specific version of Turbine and feel
comfortable that their code will compile for at least one released
version. This also gives people the chance to compile against various
previous releases to do incremental upgrades and find out what will
break in the next release.
</li>
<li>
Any time a method is deprecated, notification <strong>MUST</strong> be
sent to the developer mailing list documenting the methods that have
been deprecated as well as the alternative use. This will allow people
to search the archives and find out when and why a method was deprecated
as well as the procedure for upgrading to the latest methodology.
</li>
<li>
Items that are not Java code related and cannot be deprecated (such as
property key changes and DTD modifications) must be documented on the
mailing list.
</li>
<li>
All documentation must be updated at the time of modification to reflect
the latest status of the code.
</li>
<li>
Any patches or commits that do not follow these rules will be rejected
and it is up to the person who has either checked in the modifications
or sent the patch to submit a new patch, fix the problem or back the
code out of CVS.
</li>
</ol>
</p>
</blockquote>
</td></tr>
</table>
</td>
</tr>
<!-- FOOTER -->
<tr><td colspan="2">
<hr noshade="" size="1"/>
</td></tr>
<tr><td colspan="2">
<div align="center"><font color="#525D76" size="-1"><em>
Copyright © 1999-2001, Apache Software Foundation
</em></font></div>
</td></tr>
</table>
</body>
</html>
<!-- end the processing -->
1.1 jakarta-turbine/xdocs/deprecation.xml
Index: deprecation.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Turbine Deprecation Policy</title>
<author email="jon@latchkey.com">Jon S. Stevens</author>
</properties>
<body>
<section name="Turbine Deprecation Policy">
<p>
In order for people to be comfortable with development of code based on
Turbine and not have to constantly worry about the rug being pulled out
from underneath them, we have instituted the following policy. Our goal
is to take this matter as an extremely serious practice.
</p>
<p>
<ol>
<li>
<strong>ALL</strong> existing class and method modification needs to go
through a deprecation phase. We realize that this may make some of the
API code look a bit ugly when you look at the source code, but this is a
MUST have. It is recommend that developers who deprecate methods move
them to the bottom of the .java file.
</li>
<li>
The amount of time between deprecation and removal must be at least one
release of Turbine. In other words, we can deprecate something in 2.1
and remove it in the release of 2.1.1. The amount of time between 2.1
and 2.1.1 could be measured in days, not months. The reason why we do
not feel that time is of importance is because 6 months may not be a
long enough time for a project to keep up and 2 weeks might be fine for
another project. By focusing on deprecation through releases, people can
choose to code against a specific version of Turbine and feel
comfortable that their code will compile for at least one released
version. This also gives people the chance to compile against various
previous releases to do incremental upgrades and find out what will
break in the next release.
</li>
<li>
Any time a method is deprecated, notification <strong>MUST</strong> be
sent to the developer mailing list documenting the methods that have
been deprecated as well as the alternative use. This will allow people
to search the archives and find out when and why a method was deprecated
as well as the procedure for upgrading to the latest methodology.
</li>
<li>
Items that are not Java code related and cannot be deprecated (such as
property key changes and DTD modifications) must be documented on the
mailing list.
</li>
<li>
All documentation must be updated at the time of modification to reflect
the latest status of the code.
</li>
<li>
Any patches or commits that do not follow these rules will be rejected
and it is up to the person who has either checked in the modifications
or sent the patch to submit a new patch, fix the problem or back the
code out of CVS.
</li>
</ol>
</p>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org