From abc014e5e4854c87cf6c2ee1650721114fe88060 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Wed, 17 May 2023 12:25:40 -0500 Subject: [PATCH 1/3] Introduce initial GA ADR --- ...-zarf-definition-of-generally-available.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 adr/0016-zarf-definition-of-generally-available.md diff --git a/adr/0016-zarf-definition-of-generally-available.md b/adr/0016-zarf-definition-of-generally-available.md new file mode 100644 index 0000000000..25a47a30b5 --- /dev/null +++ b/adr/0016-zarf-definition-of-generally-available.md @@ -0,0 +1,37 @@ +# 16. Zarf Definition of Generally Available + +Date: 2023-05-17 + +## Status + +Accepted + +## Context + +Eventually Zarf needs to become a "Generally Available" v1.x.x product that people can rely on for mission critical operations. Today, Zarf can be used in these environments, but it requires someone who is more involved in the Zarf lifecycle than a normal consumer/user to make that successful due to the regular introduction of breaking changes and the lack of testing in certain areas. + +## Decision + +To make Zarf a Generally Available product we need to focus on overall stability and mechanisms to ensure that stability long-term. "Stability" in this case is both that of the features we release and of the APIs and schemas that we present to consumers of Zarf. + +In order to increase this stability we decided on implementing the following: + +- Mechanism / branching strategy to backport patch fixes to older minor releases +- Clear definition of `released`, `beta`, and `alpha` features including a matrix of their support across OSes +- End to End testing that covers the `released` features outlined in that feature matrix - this should also be done: + - across operating systems (specifically: Windows, macOS, Linux) + - across major k8s distros (specifically: K3d, K3s, Minikube, Kind, EKS, AKS, OpenShift) + - across registry providers (specifically: Docker Distribution, ECR, ACR) + - across git providers (specifically: Gitea, GitLab) +- Unit testing that covers our library code (`src/pkg`) for people using Zarf as a library (code coverage metric TBD) +- Mechanisms and tests to not break compatibility with packages built with older versions of Zarf +- Mechanisms and tests to notify users when they may need to upgrade the Zarf Agent (or Pepr capability) +- Mechanisms to ensure users can easily access documentation specific to the version of Zarf they use +- Mechanisms to ensure a more seamless Zarf install experience (i.e. macOS binary signing, `sudo apk add zarf`, `asdf install zarf X.X.X`) +- Regularly published/maintained example package(s) for tutorials/quick install + +> ⚠️ **Note**: Some of these items are already addressed in Zarf but were included for completeness. + +## Consequences + +Once these are in place we will have many mechanisms to manage Zarf's stability over time but are also signing ourselves up to maintain this promise over the long-term which will increase the burden on the team and reduce our overall velocity - this is good / normal as the project matures but we will need to recognize that we won't have as much flexibility once we reach GA. From 7f9137be86a6126dbcd6a73d49bf90c3370585a7 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Wed, 17 May 2023 13:03:08 -0500 Subject: [PATCH 2/3] Add a bit more about how this will affect others too --- adr/0016-zarf-definition-of-generally-available.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/adr/0016-zarf-definition-of-generally-available.md b/adr/0016-zarf-definition-of-generally-available.md index 25a47a30b5..84f3751d46 100644 --- a/adr/0016-zarf-definition-of-generally-available.md +++ b/adr/0016-zarf-definition-of-generally-available.md @@ -29,9 +29,12 @@ In order to increase this stability we decided on implementing the following: - Mechanisms to ensure users can easily access documentation specific to the version of Zarf they use - Mechanisms to ensure a more seamless Zarf install experience (i.e. macOS binary signing, `sudo apk add zarf`, `asdf install zarf X.X.X`) - Regularly published/maintained example package(s) for tutorials/quick install +- Clear definition / strategy for "what Zarf is" including clear docs on how to use `released` features > ⚠️ **Note**: Some of these items are already addressed in Zarf but were included for completeness. ## Consequences Once these are in place we will have many mechanisms to manage Zarf's stability over time but are also signing ourselves up to maintain this promise over the long-term which will increase the burden on the team and reduce our overall velocity - this is good / normal as the project matures but we will need to recognize that we won't have as much flexibility once we reach GA. + +This will also affect how Zarf is supported / marketed beyond the core team and we should consider how Zarf "GA" will affect those teams and ensure that they are ready to take on any additional burden as well. From db146d2f82217e4864aa3da80ff66cc3b53da869 Mon Sep 17 00:00:00 2001 From: Wayne Starr Date: Wed, 17 May 2023 14:05:23 -0500 Subject: [PATCH 3/3] Add feedback about the ADR --- adr/0016-zarf-definition-of-generally-available.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/adr/0016-zarf-definition-of-generally-available.md b/adr/0016-zarf-definition-of-generally-available.md index 84f3751d46..f4cadb4273 100644 --- a/adr/0016-zarf-definition-of-generally-available.md +++ b/adr/0016-zarf-definition-of-generally-available.md @@ -18,6 +18,7 @@ In order to increase this stability we decided on implementing the following: - Mechanism / branching strategy to backport patch fixes to older minor releases - Clear definition of `released`, `beta`, and `alpha` features including a matrix of their support across OSes +- Clear definition of when backwards compatibility checks are going to be removed with clear messaging to users - End to End testing that covers the `released` features outlined in that feature matrix - this should also be done: - across operating systems (specifically: Windows, macOS, Linux) - across major k8s distros (specifically: K3d, K3s, Minikube, Kind, EKS, AKS, OpenShift) @@ -25,7 +26,7 @@ In order to increase this stability we decided on implementing the following: - across git providers (specifically: Gitea, GitLab) - Unit testing that covers our library code (`src/pkg`) for people using Zarf as a library (code coverage metric TBD) - Mechanisms and tests to not break compatibility with packages built with older versions of Zarf -- Mechanisms and tests to notify users when they may need to upgrade the Zarf Agent (or Pepr capability) +- Mechanisms to notify users when they may need to upgrade the Zarf Agent (or Pepr capability) - Mechanisms to ensure users can easily access documentation specific to the version of Zarf they use - Mechanisms to ensure a more seamless Zarf install experience (i.e. macOS binary signing, `sudo apk add zarf`, `asdf install zarf X.X.X`) - Regularly published/maintained example package(s) for tutorials/quick install