Add stable release policy to developers documentation.
* Write stable-release-policy.md for upcoming stable release. * Remove unused Doxygen options from Doxyfile.
This commit is contained in:
Wayne Stambaugh
parent
6728f0a863
commit
5c952a2afa
|
|
@ -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
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue