From 21903233699fa40f7fb7f2bf7f0eb6e6e13efca6 Mon Sep 17 00:00:00 2001
From: Gianluca Arbezzano <gianarb92@gmail.com>
Date: Wed, 2 Sep 2020 10:08:38 +0200
Subject: [PATCH] 0011: how to communicate bc-break

---
 0011/README.md | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)
 create mode 100644 0011/README.md

diff --git a/0011/README.md b/0011/README.md
new file mode 100644
index 0000000..01377b0
--- /dev/null
+++ b/0011/README.md
@@ -0,0 +1,62 @@
+---
+id: 0011
+title: how to announce bc break for Tinkerbell
+status: discussion
+authors: Name <gianarb92@gmail.com>
+---
+
+## Summary
+
+At this stage, where the various services are not released and do not have
+semver we can accept BC break.
+
+We need to have a consolidate way to communicate them.
+
+## Goals and no-Goals
+
+Goal:
+
+* Clarify the way we can communicate bc break across services and in Tinkerbell.
+* A solution with low overhead that has to work NOW.
+
+No-Goal:
+
+* Explain how SemVer manage Bc-Break or how we will communicate bc-break when
+  SemVer will be in use.
+* Explain how a component should communicate bc-break to their community.
+
+## Content
+
+Even if we do not expect many BC break the possibility to remove or change a
+functionality is a luxury that won't stay for long.
+
+Even if we don't have a day for the first major release of Tinkerbell or for the
+other component I doubt it will be next week, this means that BC break are
+expected and we need to communicate them effectively.
+
+Every PR that introduce a BC break will get labeled with a `bc-break` label. In
+this way we will be able to build a workflow that programmatically will extract
+the BC-Break for every component.
+
+Every PR has to contain as part of the description a section titled:
+"how to migrate" teaching the user about how it should pass from a previous
+version to a new one when possible. If not possible because the section will
+explain why we remove the entire functionality and will offer an alternative if
+it exists.
+
+With the idea that every component should be independent and interchangeable I
+don't want to write as part of this PR how boots, osie will have to communicate
+their BC break to the outside, but we need to agree at minimum to be able to
+communicate them to the all Tinkerbell community.
+
+[tinkerbell/sandbox](https://github.com/tinkerbell/sandbox) is the way the
+community interacts with Tinkerbell following the documentation (not true yet
+but very soon). The sandbox project will follow a semver and it will bump a
+major release when required, in general it should report as part of the
+changelog the bc-break from the underline component.
+
+## System-context-diagram
+
+## APIs
+
+## Alternatives