Add stable release policy to developers documentation.

# Doxyfile 1.8.2

# Doxyfile 1.8.2

# This file describes the settings to be used by the documentation system

# This file describes the settings to be used by the documentation system

TYPEDEF_HIDES_STRUCT   = 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

# 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

# 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

# their name and scope. Since this can be an expensive process and often the

# directories like "/usr/src/myproject". Separate the files or directories

# directories like "/usr/src/myproject". Separate the files or directories

# with spaces.

# 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

# 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

# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is

# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py

# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py

# *.f90 *.f *.for *.vhd *.vhdl

# *.f90 *.f *.for *.vhd *.vhdl

FILE_PATTERNS          = *.md

FILE_PATTERNS          =

# The RECURSIVE tag can be used to turn specify whether or not subdirectories

# 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.

# should be searched for input files as well. Possible values are YES and NO.

XML_OUTPUT             = xml

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

XML_PROGRAMLISTING     = YES

#---------------------------------------------------------------------------

#---------------------------------------------------------------------------

# Road Map # {#mainpage}

# Road Map #

This document is the KiCad Developer's road map document.  It is a living

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

document that should be maintained as the project progresses.  The goal of

# 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.