add release plan and alternatives

Signed-off-by: Paul Schultz <pschultz@pobox.com>
2024-06-10 12:32:32 -05:00
parent acea14b422
commit 62abf939d8
1 changed files with 4 additions and 13 deletions
@@ -29,6 +29,7 @@ creation-date: 2024-06-04
  - [Release Plan](#release-plan)
  - [Dependencies](#dependencies)
  - [Alternatives](#alternatives)
+    - [Create a Separate Winston Logger Instance](#create-a-separate-winston-logger-instance)

 ## Summary

@@ -275,13 +276,7 @@ export interface AuditLogger {

 ## Release Plan

-WIP
-
-<!--
-This section should describe the rollout process for any new features. It must take our version policies into account and plan for a phased rollout if this change affects any existing stable APIs.
-
-If there is any particular feedback to be gathered during the rollout, this should be described here as well.
-->
+The release plan involves initially creating a shared audit log package. Following this, the audit log will be implemented in core packages and other plugins. The first targets should be high-priority areas, such as the scaffolder and catalog systems. Since adding the audit log will not disrupt existing functionality, the release plan is simplified.

 ## Dependencies

@@ -289,10 +284,6 @@ If there is any particular feedback to be gathered during the rollout, this shou

 ## Alternatives

-WIP
+### Create a Separate Winston Logger Instance

-<!--
-What other approaches did you consider, and why did you rule them out? These do
-not need to be as detailed as the proposal, but should include enough
-information to express the idea and why it was not acceptable.
-->
+We could create a separate instance of the Winston logger. However, this approach would necessitate core packages and plugins to include an additional argument in their constructor.