HACKING

= Guide to Hacking Archive::Zip

== Licensing

Contributed code must be licensed under the same license as this project.  See
the included LICENSE file for details.  Special consideration MAY be made in
some cases, but such cases will be rare.


== Dependencies

=== Runtime

* Ruby 1.8.6 or greater
* io-like 0.3.0 or greater


=== Build

* rubygems 1.8.8 or greater
* rake 0.9.2 or greater
* rdoc 3.9.2 or greater
* mspec 1.5.17 or greater


=== Install

* rubygems 0.9.0 or greater


== Versioning Policy

Version numbers will be in <em>x.y.z</em> format, where <em>x</em>, <em>y</em>,
and <em>z</em> are integers starting from 0.  The version increment rules are
as follows:

<b>x</b>:: Planned releases which implement significant changes and/or break API
           compatibility.  An exception is to be made for the transition from
           the <em>0.y.z</em> series to the <em>1.y.z</em> series since the
           <em>0.y.z</em> series is expected to be unstable throughout
           development.  When incremented, <em>y</em> and <em>z</em> are reset
           to 0.
<b>y</b>:: Planned releases which incorporate numerous bug fixes and/or new
           features which do not break backward compatibility.  When
           incremented, <em>z</em> is reset to 0.
<b>z</b>:: Generally, unplanned releases which incorporate a single fix for a
           critical defect.

This is the {Rational Versioning Policy}[http://www.rubygems.org/read/chapter/7]
as outlined in the {RubyGems User Guide}[http://www.rubygems.org/read/book/1].


== Support Policy

Due to limitations in resources (time/money/manpower), this project will focus
primarily upon the development line of the current release at any given time.
Fixes and new features should be applied first to that development line and then
backported to earlier releases if necessary and feasible.  Long term maintenance
of previous releases is not planned.  Users are generally expected to upgrade to
the latest release in order to receive updates unless an explicit declaration of
support for a previous release is made.


== Coding Style

The following points are not necessarily set in stone but should rather be used
as a good guideline.  Consistency is the goal of coding style, and changes will
be more easily accepted if they are consistent with the rest of the code.

<b>File Encoding</b>::     UTF-8
<b>Indentation</b>::       Two spaces; no tabs
<b>Comments</b>::          Document classes, attributes, methods, and code
<b>Boolean Operators</b>:: Use <tt>&&</tt> and <tt>||</tt> for boolean tests;
                           avoid <tt>and</tt> and <tt>or</tt>
<b>Method Calls</b>::      Use <tt>a_method(arg, arg, etc)</tt>; <b>not</b>
                           <tt>a_method( arg, arg, etc )</tt>,
                           <tt>a_method arg, arg, etc</tt>, or any other
                           variation
<b>Blocks</b>::            <tt>do end</tt> for multi-line blocks and
                           <tt>{ }</tt> for single-line blocks
<b>Line length</b>::       Limit lines to a maximum of 80 characters
<b>General</b>::           Try to follow the flow and style of the rest of the
                           code


== Contributing Code

Making a contribution is pretty simple.  Fork the project on Github
(http://github.com/javanthropus/archive-zip), make your changes, and submit a
pull request.  Requests that meet the following criteria will be the most
readily accepted:

1. Each pull request should target an individual issue and should introduce
   relatively few commits.
2. Individual commits need to be small, easily digestible units.
3. Good descriptions of the changes introduced should be included in each commit
   message.
4. Interdependencies on existing pull requests need to be noted in the pull
   request.
5. New test cases are a major plus.
6. Documentation for new classes, methods, etc. is also a win.
7. The coding style of the project should be respected.

In other words, the less work necessary to bring your changes into the project,
the faster you can expect them to be pulled.