Updates to documentation in preparation of bugfix release.

docs/BreakingChanges.md

@@ -187,7 +187,7 @@ The following features have all been removed from Ceedling's functionality. No n
 
  - `options:blah.yml` command-line options (see `--mixin` command line option)
  - The corresponding `options_paths:` key in the project.yml file no longer has any effect. (see `:mixins:` ➡️ `:load_paths:` project.yml specification)
- - The `project.yml` file now specifies other yaml files to load using the `:mixins:` ➡️ `:enabled:` section
+ - The `:import:` section of the `project.yml` has been replaced (see `:mixins:` ➡️ `:enabled:` section)
  - `CEEDLING_PROJECT_FILE` environment variable (see `CEEDLING_MIXIN_#` specification)
  - `CEEDLING_SER_FILE` environment variable (see `CEEDLING_MIXIN_#` specification)
 

docs/Changelog.md

@@ -9,6 +9,25 @@ This changelog is complemented by two other documents:
 
 ---
 
+# [1.0.1] - 2025-01-30
+
+## 💪 Fixed
+
+- `#978` -- Ceedling attempts to link source files that are commented out and/or removed by preprocessor directives
+- `#979` -- FFF plugin generates "warning: already initialized constant CMock" on some platforms
+- `#980` -- FFF original plugin should not be part of release build (le sigh)
+- `#981` -- Ceedling could not find header file to mock when using preprocessor
+- `#982` -- Ceedling did not inject required header file into mock when using preprocessor
+- `#985` -- Macros not being properly hidden from CMock's parser when using preprocessor
+- `#988` -- Parsing of `TEST_SOURCE_FILE` did not support special characters (like `.`) in filenames
+- `#888` & `#977` -- Unicode characters produce crashes in various places
+- `#996` -- Improved handling and documentation of module generator path options
+- `#998` -- FFF plugin missing required stringio
+- `#1005` -- Additional handling of preprocessing extraction improvements
+- Restored `:use_mocks` default to `true` in Ceedling defaults to match documentation and other mocking defaults in template projects.
+- Resolved a preprocessing issue that could cause the content of a file having a similar filename to that of the file `#include`ing it to become mixed with that file.
+- additional documentation improvements
+
 # [1.0.0] — 2025-01-01
 
 ## 🌟 Added

docs/ReleaseNotes.md

@@ -7,6 +7,14 @@ These release notes are complemented by two other documents:
 
 ---
 
+# 1.0.1 - January 30, 2025
+
+This is a collection of bugfixes found after the 1.0.0 release. If you are upgrading from a pre-1.0 release of Ceedling, we highly recommend reading the `1.0.0` release notes as well!
+
+See [Changelog](Changelog.md) for a full list of bugfixes and improvements.
+
+The most significant issues addressed with this release are problems with preprocessor handling, particularly when discovering which header files are required for each test. If you were running into similar problems with `1.0.0`, we highly recommend this upgrade.
+
 # 1.0.0 — January 01, 2025
 
 **This Ceedling release is probably the most significant since the project was first [posted to SourceForge in 2009][sourceforge].**

docs/SECURITY.md

@@ -0,0 +1,41 @@
+# Security Policies and Procedures
+
+This document outlines security procedures and general policies for all `ThrowTheSwitch.org`
+projects, including `Unity`, `CMock`, and `Ceedling`.
+
+  * [Reporting a Bug](#reporting-a-bug)
+  * [Disclosure Policy](#disclosure-policy)
+  * [Comments on this Policy](#comments-on-this-policy)
+
+## Reporting a Bug
+
+The tools from `ThrowTheSwitch.org` are made to collaborate with other tools like compilers, 
+simulators, and such, and therefore have very low-level access to the world they live in. 
+However, they are typically used in controlled development-centered environments. As such, 
+they are typically not directly exposed to security concerns. 
+
+The `ThrowTheSwitch.org` community takes security bugs seriously. Where possible, we will
+make every effort to improve our tools safe use. Thank you for improving the security of 
+our tools. We appreciate your efforts and responsible disclosure and will make every effort 
+to acknowledge your contributions.
+
+Report security bugs by opening a Github Issue on the corresponding project or (when this
+itself would pose a risk) by emailing [email protected].
+
+Report security bugs in third-party modules to the person or team maintaining
+the module.
+
+## Disclosure Policy
+
+Each issue will be assigned to a primary handler. This person will coordinate the fix and 
+release process, involving the following steps:
+
+  * Confirm the problem and determine the affected versions.
+  * Audit code to find any potential similar problems.
+  * Prepare fixes for all releases still under maintenance. These fixes will be
+    released as fast as possible.
+
+## Comments on this Policy
+
+If you have suggestions on how this process could be improved please submit a
+pull request.