[Problem Statement] TEP-0096: Pipelines V1 Release #567
Conversation
tekton-robot
added
the
size/L
lbernick
force-pushed
the
v1
branch
2 times, most recently
from
70b3df9 to
b5ec6df
Compare
|
/kind tep |
tekton-robot
added
the
kind/tep
|
/assign |
There was a problem hiding this comment.
I am guessing this is the TEP version of tektoncd/pipeline#3548 ?
/assign
lbernick
force-pushed
the
v1
branch
2 times, most recently
from
b792714 to
feadc84
Compare
The goal of this TEP is to come to consensus on a stability policy and what features we'd like to prioritize for V1, but not to do detailed issue tracking here. Jerop and I are thinking that this will be similar to TEP-0074: Deprecate PipelineResources. |
tekton-robot
added
the
approved
lbernick
force-pushed
the
v1
branch
2 times, most recently
from
ffa5339 to
4db3534
Compare
|
@vdemeester @pritidesai @bobcatfish I'd love to be able to merge this before the next WG (12/13) because I'm hoping to start discussing in scope/out of scope features during that meeting! PTAL and let me know if you have any concerns or if you need more time with this proposal, but I'm hoping since there aren't really any changes proposed to what we're already doing, we can merge this soon 🤞 |
|
@vdemeester / @iancoffey |
teps/0096-pipelines-v1-release.md
Outdated
| ### Goals | ||
|
|
||
| - Define stability policy for Pipelines V1. | ||
| - Define supported and unsupported use cases for Pipelines V1. |
There was a problem hiding this comment.
re. our earlier discussion @lbernick , maybe "features" instead of "use cases" - depending on the direction you want to go :D
There was a problem hiding this comment.
I think we may want to have both. Feature is a "limited" set that we know we have or want to have. Use case is.. something that is outside of our control (someone could be using it for a use case we never thought of) but we could definitely clarify the use case we intend to support (non exhaustive list 😛 ) and the one we definitely do not want to support (if any)
teps/0096-pipelines-v1-release.md
Outdated
|
|
||
| ### Non Goals | ||
|
|
||
| - Define the stability or V1 plans of other Tekton project. |
There was a problem hiding this comment.
+1 to this
but at the same time, can the other Tekton projects play any role in Pipelines V1? 🤔 we discussed briefly this in API WG, there could be but we don't have concrete answer yet or we don't know yet.
There was a problem hiding this comment.
I think other Tekton projects will be important for meeting the use cases we want to support, but we can define what it means for pipelines v1 to be stable without involving features from other projects (hopefully). This seems like something that should remain an open question for now.
teps/0096-pipelines-v1-release.md
Outdated
|
|
||
| Tekton follows Kubernetes' [deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/). | ||
| However, while Kubernetes defines stability periods in terms of months or releases, whichever is longer, | ||
| Tekton defines stability periods only in terms of months. |
There was a problem hiding this comment.
This might change once we release V1, can it? The focus is months right now since Pipelines release are created every month. What is our plan to create release once we hit V1 API and/or V1 software versioning? We don't have to answer this here but I am just wondering while reading this since its being documented officially 🤣 unless I am missing the existing documentation.
There was a problem hiding this comment.
I think how often we want to create software releases is probably out of scope for the TEP, but we could choose to adopt Kubernetes language of "x months or x releases, whichever is longer". I don't see a strong reason in either direction; I think it's unlikely our release cadence would become significantly slower after a v1 release.
|
Thank you @lbernick for creating a formal proposal for this and additional shout out to all the contributors who have played a key role in getting us so far. I have left some NITs and more discussion points but since this is an iterative proposal (process), I am happy to merge it 🎉 /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, bobcatfish, pritidesai, vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This commit defines the problem statement for a stable release of Tekton pipelines. It also describes the current Pipelines deprecation policy and proposes a deprecation policy for a stable release of Pipelines. Co-authored-by: Jerop Kipruto jerop@google.com
|
Thank you @lbernick for addressing all the comments, we have received approvals from all the assignees. Its ready to merge 🎉 /lgtm |
This commit defines the problem statement for a stable release
of Tekton pipelines. It also describes the current Pipelines
deprecation policy and proposes a deprecation policy for a stable
release of Pipelines.
Co-authored-by: Jerop Kipruto jerop@google.com @jerop