Add stable release policy to developers documentation.

* Write stable-release-policy.md for upcoming stable release.
* Remove unused Doxygen options from Doxyfile.

Documentation/development/Doxyfile

@@ -1,3 +1,4 @@
+
 # Doxyfile 1.8.2
 
 # This file describes the settings to be used by the documentation system
@@ -324,22 +325,6 @@ INLINE_SIMPLE_STRUCTS  = NO
 
 TYPEDEF_HIDES_STRUCT   = NO
 
-# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
-# determine which symbols to keep in memory and which to flush to disk.
-# When the cache is full, less often used symbols will be written to disk.
-# For small to medium size projects (<1000 input files) the default value is
-# probably good enough. For larger projects a too small cache size can cause
-# doxygen to be busy swapping symbols to and from disk most of the time
-# causing a significant performance penalty.
-# If the system has enough physical memory increasing the cache will improve the
-# performance by keeping more symbols in memory. Note that the value works on
-# a logarithmic scale so increasing the size by one will roughly double the
-# memory usage. The cache size is given by this formula:
-# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
-# corresponding to a cache size of 2^16 = 65536 symbols.
-
-SYMBOL_CACHE_SIZE      = 4
-
 # Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
 # set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
 # their name and scope. Since this can be an expensive process and often the
@@ -661,7 +646,8 @@ WARN_LOGFILE           =
 # directories like "/usr/src/myproject". Separate the files or directories
 # with spaces.
 
-INPUT                  = road-map.md
+INPUT                  = stable-release-policy.md \
+                         road-map.md
 
 # This tag can be used to specify the character encoding of the source files
 # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
@@ -679,7 +665,7 @@ INPUT_ENCODING         = UTF-8
 # *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py
 # *.f90 *.f *.for *.vhd *.vhdl
 
-FILE_PATTERNS          = *.md
+FILE_PATTERNS          =
 
 # The RECURSIVE tag can be used to turn specify whether or not subdirectories
 # should be searched for input files as well. Possible values are YES and NO.
@@ -1411,23 +1397,6 @@ GENERATE_XML           = NO
 
 XML_OUTPUT             = xml
 
-# The XML_SCHEMA tag can be used to specify an XML schema,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_SCHEMA             =
-
-# The XML_DTD tag can be used to specify an XML DTD,
-# which can be used by a validating XML parser to check the
-# syntax of the XML files.
-
-XML_DTD                =
-
-# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
-# dump the program listings (including syntax highlighting
-# and cross-referencing information) to the XML output. Note that
-# enabling this will significantly increase the size of the XML output.
-
 XML_PROGRAMLISTING     = YES
 
 #---------------------------------------------------------------------------

Documentation/development/road-map.md

@@ -1,4 +1,4 @@
-# Road Map # {#mainpage}
+# Road Map #
 
 This document is the KiCad Developer's road map document.  It is a living
 document that should be maintained as the project progresses.  The goal of

Documentation/development/stable-release-policy.md

@@ -0,0 +1,80 @@
+# Stable Release Policy #
+
+This document defines the project requirements that must be satisfied in order to create a new
+stable release of the KiCad project.  It is designed to be a reference for developers and user's
+so that both groups expectations are understood.  This document is only to be modified by the
+project leader or at the request of the project leader.  It should be noted that this policy is
+not cast in stone and at any time in the future, should the decision be made by the project at
+large that it can be revised to suit the ongoing needs of the project and it's users.
+
+The current release policy is to support the concept of a lightweight stable release.  The goal
+is to provide regular stable releases of KiCad without the burden of trying to provide long term
+support of a full stable release branch.  Therefore, once a new release is created, the only
+patches that will be made to the stable release branch will be for bugs that cause KiCad to crash
+or possible corruption and/or loss of data.  No other changes from the current development branch
+will be backported to the last stable release by the project.
+
+[TOC]
+
+# Stable Release Interval # {#stable_release_interval}
+
+The criteria required for new stable releases is based on the developers decision that enough
+new features and/or improvements have been made to the current development branch to justify a
+new stable release.  This decision is completely discretionary and can be proposed at any time
+by any developer on the KiCad developers mailing list.  Once a request for a new stable release
+is made, a consensus must be reached by the primary developers to proceed with the release with
+the final decision and announcement being made by the project leader.
+
+
+# Feature Freeze # {#feature_freeze}
+
+Once the announcement has been made that a new stable release is in effect, the current
+development branch is frozen.  No new features or potentially disruptive core code changes can
+be committed with out approval of the primary developers and/or the project leader.
+
+# Bug Fixing # {#bug_fixing}
+
+After the development branch has been frozen, work will continue to fix bugs reported against
+the development branch.  Bugs will be prioritized based on their severity.  All bugs that cause
+KiCad to crash or cause loss and/or corruption of data must be fixed.  All other bugs must be
+evaluated to see if they fit into the scope of the stable release.  All bugs that fit into the
+scope of the stable release will be tagged and must be fixed.  All other bugs will be tagged for
+the next stable release and fixed when it is convenient.  Once the stable release is officially
+announced, the bugs tagged as "Fix Committed" that are relevant to the stable release will be
+changed to "Fix Released".
+
+# User Documentation # {#user_docs}
+
+The user documentation will be updated to reflect the current changes in the code.  This includes
+all new features, any behavioral changes to existing features, and all screen shots as required.
+Completion of the English version of the user documentation is minimum that is required for
+release.  Foreign language translations can be released at any time as the become available.
+
+# Stable Release Series Branch # {#stable_branch}
+
+Once the primary developers decide that the stable release criteria has been met, a new series
+branch will be created from the current product branch on Launchpad.  At this time the freeze
+will be removed from the product branch and normal development can resume.  The stable release
+version will be incremented from the previous stable release and tagged in the stable release
+branch build configuration.
+
+# System Installers # {#system_installers}
+
+To proved the best user experience for platforms that do not have package managers, full system
+installers will be provided.  Currently this only pertains to Windows and OSX.  The full system
+installers will include all KiCad binary files, all binary library dependencies, user
+documentation, component libraries, 3D model libraries, demo project files, and project template
+files.  Optionally, the footprint libraries can be included for users who prefer not us use the
+GitHub plugin.
+
+# Source Archives # {#source_archives}
+
+To provide a convenient method for system packagers to build KiCad from known stable sources,
+source archives in the most common formats along with the resulting md5sum checksum will be
+added to either the KiCad developer's site on Launchpad or the main website at www.kicad-pcb.org.
+
+# Stable Release Announcement # {#announcement}
+
+Once all of the above tasks have been completed, the project leader will post an announcement on
+the developers mailing list and the Launchpad site.  This announcement should include a list of
+new features and improvements made since the previous stable release.