-
Notifications
You must be signed in to change notification settings - Fork 19
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Gianluca Arbezzano
committed
Sep 2, 2020
1 parent
9f106de
commit 2190323
Showing
1 changed file
with
62 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |