Merging upstream version 0.1.47.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 6 insertions, 1 deletions

diff --git a/docs/IMPLEMENTATION-DECISIONS.md b/docs/IMPLEMENTATION-DECISIONS.md
index b1d3b57..b238d27 100644
--- a/docs/IMPLEMENTATION-DECISIONS.md
+++ b/docs/IMPLEMENTATION-DECISIONS.md
@@ -212,7 +212,7 @@ When loading the python code for plugins, there were multiple ways to initialize
  1. The plugin could have an initialization function that is called by `debputy`
 
  2. The plugin could use `@some_feature` annotations on types to be registered. This is similar
-    in spirit to the `add-on` system where module load is considered the initialization event.
+    in spirit to the `dh` add-on system where module load is considered the initialization event.
 
 The 1. option was chosen because it is more reliable at directing the control flow and enables
 the plugin module to be importable by non-`debputy` code. The latter might not seem directly
@@ -228,3 +228,8 @@ property (see above) or be "safety is opt-in rather than always on/opt-out" by h
 "This is plugin X code coming now" - the absence of a marker then causing misattribution).
 
 If these problems could be solved, the annotation based loading could be considered.
+
+Note: This is not to say that `@feature` cannot be used at all in the plugin code. The annotation
+can be used to add metadata to things that simplify the logic required by the initialization
+function. The annotation would have to be stateless and cannot make assumptions about which
+plugin is being loaded while it is run.