docs: how to write docs; design decision: plugin dependency (#10)

Makefile

@@ -13,7 +13,7 @@ DOCS_SERVE_CMD = mkdir -p htmlcov/ && touch htmlcov/index.html && mkdir -p docs/
 POETRY_SETUP_CMD = poetry install --all-extras --sync
 POETRY_PUBLISH_CMD = poetry build && poetry publish
 CHANGELOG_CMD = git-changelog -c angular -t keepachangelog -s build,deps,feat,fix,refactor,docs -i -o CHANGELOG.md -T --bump=auto .
-RELEASE_CMD = git add pyproject.toml CHANGELOG.md && git commit -m "release/$(version)" && git tag $(version) && git push && git push --tags
+RELEASE_CMD = git add pyproject.toml CHANGELOG.md && git commit -m "chore: prepare release $(version)" && git tag $(version) && git push && git push --tags
 
 .PHONY: setup setup-test setup-poetry clean format check test docs orm changelog publish release
 

docs/development/index.md

@@ -47,6 +47,9 @@ Different plugin types like analysis, generate, and effect exist because:
 - There are shared functionalities within each plugin class provided by Nendo Core.
 - These shared functionalities make the implementation of new plugins more effortless for developers.
 
+**Should a plugin depend on or use other plugins?**
+
+We highly advocate against having plugins depend on or use other plugins. The combining of plugins should exclusively happy by means of chaining "from the outside" of Nendo. The reason for this is, that there is a high likelyhood of introducing a dependency conflict if the original project uses say `plugin_a` of a specific version but another plugin, `plugin_b` depends on `plugin_a`, but of another version.
 
 ## Writing Good Documentation
 

mkdocs.yml

@@ -34,7 +34,6 @@ nav:
 - Development:
   - development/index.md
   - Contributing: contributing.md
-  - Documentation: development/documentation.md
   - Plugin Development:
     - development/plugindev.md
     - Analysis Plugin: development/analysisplugindev.md