<commit_before><!DOCTYPE html>
<HTML>
<!-- SECTION: Specifications -->
<HEAD>
	<TITLE>CUPS Developer Guide</TITLE>
	<LINK REL="STYLESHEET" TYPE="text/css" HREF="../cups-printable.css">
</HEAD>
<BODY>

<H1 CLASS="title">CUPS Developer Guide</H1>

<P>This developer guide documents the guidelines and processes we use when developing and maintaining CUPS and related software. Our goal is to provide reliable and efficient software and documentation that addresses the needs of our users.</P>


<H2 CLASS="title"><A NAME="OVERVIEW">Overview</A></H2>

<P>CUPS is developed by Apple Inc. and distributed as open source software under a combination of GNU GPL2 and GNU LGPL2 licenses with exceptions to allow linking to OpenSSL (which has a GPL-incompatible license) and for developers on Apple's operating systems to develop CUPS-based software until alternate license terms. Significant contributions to CUPS must be licensed to Apple using the <A HREF="https://www.cups.org/AppleContributorAgreement_2011-03-10.pdf">Apple Contributor Agreement</A>.</P>

<P>Apple releases updates to the CUPS software approximately every three months. Each release has a version number consisting of the major version (currently 1), minor version (currently 6), and patch version (starting at 0) separated by the period, for example "1.6.0". Releases where only the patch version number changes will contain only bug fixes to the previous release, for example "1.6.1" includes bug fixes for the "1.6.0" release. New features require the major or minor version numbers to change, for example "1.6.0" release contains new features compared to the "1.5.3" release. Multiple beta and "candidate" releases generally precede each new feature release, for example "1.5b1", "1.5b2", and "1.5rc1" preceded the "1.5.0" release. Finally, we also post regular Subversion snapshot releases, for example "1.6svn-r10486", which represent a snapshot of the development for the next feature release.</P>

<P>CUPS interfaces, including the C APIs and command-line arguments, environment variables, configuration files, and output format, are stable across patch versions and are generally backwards-compatible with interfaces used in prior major and minor versions. However, program interfaces such as those used by the scheduler to run filter, port monitor, and backend processes for job processing should only be considered stable from the point of view of a filter, port monitor, or backend. Software that simulates the scheduler in order to run those programs outside of CUPS must necessarily be updated when the corresponding interface is changed in a subsequent CUPS release, otherwise undefined behavior can occur.</P>

<P>CUPS C APIs starting with an underscore (_) are considered to be private to CUPS and are not subject to the normal guarantees of stability between CUPS releases and must <em>never</em> be used in non-CUPS source code. Similarly, configuration and state files written by CUPS are considered private if a corresponding man page is not provided with the CUPS release. <em>Never</em> rely on undocumented files or formats when developing software for CUPS. <em>Always</em> use a published C API to access data stored in a file to avoid compatibility problems in the future.</P>


<H2 CLASS="title"><A NAME="COMMUNICATION">Communication</A></H2>

<H3><A NAME="CONTACT">How to Contact the Developers</A></H3>

<P>The <A HREF="https://www.cups.org/lists.php">CUPS.org mailing lists</A> are the primary means of asking questions and informally discussing issues and feature requests with the CUPS developers and other experienced CUPS users and developers. The <a href="https://www.cups.org/mailman/listinfo/cups">cups&#x40;cups.org</a> mailing list is intended for CUPS usage questions and new software announcements while the <a href="https://www.cups.org/mailman/listinfo/cups-devel">cups-devel&#x40;cups.org</a> mailing list provides a forum for CUPS developers and monitoring new bugs.</p>


<H3><A NAME="SUBMIT">How to Submit a Bug Report or Feature Request</A></H3>

<P>The CUPS.org <A HREF="https://www.cups.org/str.php">Bugs</A> page provides access to the CUPS <em>Software Trouble Report</em> (STR) database and is the formal way to submit a bug report or feature request to the CUPS developers. Please note, however, that we <em>do not</em> provide answers to usage questions or resolve problems in third-party software on this page - use the <A HREF="#CONTACT">CUPS.org mailing lists</A> for that instead.</P>

<P>Unlike discussions that occur on the CUPS.org mailing lists, formal bug reports and feature requests must be acted on by the CUPS developers. This does not mean that every bug report is resolved or every feature request is implemented, but we do respond and keep track of them all for posterity.</P>

<BLOCKQUOTE><B>Note:</B>

<P>Please use the search feature of the Bugs page before submitting a new bug report or feature request. If you see an existing report that matches your issue, please post a message to that report ("I have this issue as well", "I would also like to see", etc.) rather than submitting a new report. This helps speed the resolution of your issue by reducing the CUPS developers' work load and identifying popular issues.</P></BLOCKQUOTE>


<H3><A NAME="PATCH">How to Prepare a Patch</A></H3>

<P>When submitting a bug report or feature request, you can include patch files that resolve the bug or implement the feature to speed the inclusion of that bug fix or feature in a new CUPS release. For changes to existing files, we prefer a unified diff against the current GIT "master" branch, which can be generated easily using the following Git command:</P><commit_msg>Fix typo, remove reference to OpenSSL.<commit_after><!DOCTYPE html>
<HTML>
<!-- SECTION: Specifications -->
<HEAD>
	<TITLE>CUPS Developer Guide</TITLE>
	<LINK REL="STYLESHEET" TYPE="text/css" HREF="../cups-printable.css">
</HEAD>
<BODY>

<H1 CLASS="title">CUPS Developer Guide</H1>

<P>This developer guide documents the guidelines and processes we use when developing and maintaining CUPS and related software. Our goal is to provide reliable and efficient software and documentation that addresses the needs of our users.</P>


<H2 CLASS="title"><A NAME="OVERVIEW">Overview</A></H2>

<P>CUPS is developed by Apple Inc. and distributed as open source software under a combination of GNU GPL2 and GNU LGPL2 licenses with exceptions to allow developers on Apple's operating systems to develop CUPS-based software under alternate license terms. Significant contributions to CUPS must be licensed to Apple using the <A HREF="https://www.cups.org/AppleContributorAgreement_2011-03-10.pdf">Apple Contributor Agreement</A>.</P>

<P>Apple releases updates to the CUPS software approximately every three months. Each release has a version number consisting of the major version (currently 1), minor version (currently 6), and patch version (starting at 0) separated by the period, for example "1.6.0". Releases where only the patch version number changes will contain only bug fixes to the previous release, for example "1.6.1" includes bug fixes for the "1.6.0" release. New features require the major or minor version numbers to change, for example "1.6.0" release contains new features compared to the "1.5.3" release. Multiple beta and "candidate" releases generally precede each new feature release, for example "1.5b1", "1.5b2", and "1.5rc1" preceded the "1.5.0" release. Finally, we also post regular Subversion snapshot releases, for example "1.6svn-r10486", which represent a snapshot of the development for the next feature release.</P>

<P>CUPS interfaces, including the C APIs and command-line arguments, environment variables, configuration files, and output format, are stable across patch versions and are generally backwards-compatible with interfaces used in prior major and minor versions. However, program interfaces such as those used by the scheduler to run filter, port monitor, and backend processes for job processing should only be considered stable from the point of view of a filter, port monitor, or backend. Software that simulates the scheduler in order to run those programs outside of CUPS must necessarily be updated when the corresponding interface is changed in a subsequent CUPS release, otherwise undefined behavior can occur.</P>

<P>CUPS C APIs starting with an underscore (_) are considered to be private to CUPS and are not subject to the normal guarantees of stability between CUPS releases and must <em>never</em> be used in non-CUPS source code. Similarly, configuration and state files written by CUPS are considered private if a corresponding man page is not provided with the CUPS release. <em>Never</em> rely on undocumented files or formats when developing software for CUPS. <em>Always</em> use a published C API to access data stored in a file to avoid compatibility problems in the future.</P>


<H2 CLASS="title"><A NAME="COMMUNICATION">Communication</A></H2>

<H3><A NAME="CONTACT">How to Contact the Developers</A></H3>

<P>The <A HREF="https://www.cups.org/lists.php">CUPS.org mailing lists</A> are the primary means of asking questions and informally discussing issues and feature requests with the CUPS developers and other experienced CUPS users and developers. The <a href="https://www.cups.org/mailman/listinfo/cups">cups&#x40;cups.org</a> mailing list is intended for CUPS usage questions and new software announcements while the <a href="https://www.cups.org/mailman/listinfo/cups-devel">cups-devel&#x40;cups.org</a> mailing list provides a forum for CUPS developers and monitoring new bugs.</p>


<H3><A NAME="SUBMIT">How to Submit a Bug Report or Feature Request</A></H3>

<P>The CUPS.org <A HREF="https://www.cups.org/str.php">Bugs</A> page provides access to the CUPS <em>Software Trouble Report</em> (STR) database and is the formal way to submit a bug report or feature request to the CUPS developers. Please note, however, that we <em>do not</em> provide answers to usage questions or resolve problems in third-party software on this page - use the <A HREF="#CONTACT">CUPS.org mailing lists</A> for that instead.</P>

<P>Unlike discussions that occur on the CUPS.org mailing lists, formal bug reports and feature requests must be acted on by the CUPS developers. This does not mean that every bug report is resolved or every feature request is implemented, but we do respond and keep track of them all for posterity.</P>

<BLOCKQUOTE><B>Note:</B>

<P>Please use the search feature of the Bugs page before submitting a new bug report or feature request. If you see an existing report that matches your issue, please post a message to that report ("I have this issue as well", "I would also like to see", etc.) rather than submitting a new report. This helps speed the resolution of your issue by reducing the CUPS developers' work load and identifying popular issues.</P></BLOCKQUOTE>


<H3><A NAME="PATCH">How to Prepare a Patch</A></H3>

<P>When submitting a bug report or feature request, you can include patch files that resolve the bug or implement the feature to speed the inclusion of that bug fix or feature in a new CUPS release. For changes to existing files, we prefer a unified diff against the current GIT "master" branch, which can be generated easily using the following Git command:</P>
{'fraction_non_alphanumeric': 0.0778569543415149, 'fraction_numerical': 0.011084718923198733, 'mean_word_length': 4.9580712788259955, 'pattern_counts': {'":': 0, '<': 157, '<?xml version=': 0, '>': 157, 'https://': 10, 'lorem ipsum': 0, 'www.': 10, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6501694', 'n_tokens_mistral': 3094, 'n_tokens_neox': 2863, 'n_words': 1572}