Contributor recipe guide
Note: this document covers modules, but themes, theme engines, and translations are essentially the same.
<h2>Adding a new module to CVS</h2>
First, check out the modules directory from the HEAD version of the contributions repository:
<pre>
cvs -d:pserver:<strong>cvs_username</strong>@cvs.drupal.org:/cvs/drupal-contrib checkout -l contributions/modules
</pre>
Next, copy your module files into the contributions/modules directory.
<code>
cd contributions/modules
cp -r ~/drupal/modules/foo foo
</code>
Finally, add your changes to CVS.
<code>
cvs add foo
cvs add foo/*
cvs commit -m "Adding foo module."
</code>
<h2>Saving changes to your module</h2>
Bugs and features are tracked in your project's <a href="http://drupal.org/project/issues">issue queue</a>. It is customary in the commit message to reference the node ID of the issue where the bug/feature request was raised, and mention any contributors who helped with the code.
<code>
cvs commit -m "#12345 by username. Brief description of changes."
</code>
<h2>Branching for a specific Drupal version</h2>
In order to make it clear which Drupal version your module is for,
<h2>Creating an official release</h2>
Once your module gets to the point where it is relatively stable, it's time to create an official release for it. You do this by tagging the module files. Here is an example that makes a "1.0" release of the Druapl
<code>
cd contributions/modules/your_module
cvs update -r DRUPAL-4-7 # updates to the end of the DRUPAL-4-7 branch
cvs tag DRUPAL-4-7--1-0 # creates the release tag for the "4.7.x-1.0" release.
</code>
<h2>Creating a development snapshot release of your module</h2>
In order to allow people to test your module while it is in development, you may wish to make a development snapshot. This will create a