-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tekton Coordinated releases #413
Comments
Whatever we choose to do here, I'm a firm believer that releasing frequently and always being in a releasable state are keys to high quality and velocity. I would like to add a couple requirements which I hope we can meet in the solution we come up with:
The key thing I'm trying to get at is that I want to avoid introducing delays and extra human effort into the release process as much as possible. There might be some overlap with tektoncd/pipeline#2746 as well. A couple of ideas to add to the pile:
I think it's also worth identifying the dependencies between projects:
A couple thoughts from this list:
|
If this is really the main problem we're solving, I wonder if there is a way you could use tools to make this process smoother. For example for the CLI, what if you could install a version of tkn and then tell it to update itself to the version of Tekton Pipelines you wanted to use? This reminds me of tektoncd/cli#649 which would involve the CLI being able to tell if it is compatible with the tekton pipelines installation it is configured to use. We could take that a step further and use tkn as an interface for configuring your tekton installation: check the version of pipelines/triggers installed (maybe install it for you), install the appropriate version of dashboard, maybe even update itself. |
For what is worth, I really like knative's approach on there, where the releases are "date" based and shared across all the components (and automated). All components of version X are supposed to work with other components of the same version. This is especially true when you have the
It is not. The main problem we "may" want to solve, is for the user to easily know what version of components he has installed. Having one version to rule them all makes it easy. This is particularly true with something like the operator ( It is also the case for the cli by the way : as of today, The same question will come when we are going to want to declare Tekton as GA and have a version 1.0. By "Tekton GA" or v1.0, what is GA ? what components ? … This may not be the way to go for the operator though. We may adopt a completely unrelated versioning but then, we may confuse our users.
For the cli, yes the world is now already, we do support multiple version as much as possible (best effort). My guess is that it would be the same for dashboard.
Yes, and this would be done "simplified" by updating the operator and letting it do its thing (if there is object migration to be done, …). But this only work in some cases where you can upgrade tekton yourself (it will not be the case for OpenShift pipelines for example or for most users). That's the job of the operator (as |
There is a compatibility matrix between triggers and pipeline though.
|
@wlynch related to discussion on version selection for the web site |
I totally agree with this. However, one thing have observed is that most of the time the separation between Pipelines, Triggers, etc is visible only to us, the developers. Most of the users see at Tekton (not components) as a CICD solution. So i believe it will be a great improvement of our enduser-experience, If we could make them not think about figuring out which version goes with what, or what versions of the component do i have (while reporting bugs). So I definitely see value in syncing our releases (minor versions). |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
oh i didnt know this was closed! since it's on the roadmap i'd like to keep it open /lifecycle frozen |
The lack of well-coordinated versions resulted in multiple issues in Pipelines
We need to support forwards / backwards compatibility when we release components. |
In the discussion on operator versioning one of the options is for Tekton components to share version numbers.
Today all components release independently from each other.
When a component introduces support for a version of another component, that information is stored on the release notes, but we don't have any mechanism in place to surface that in an easy to consume format (e.g. on the website, or in the docs of all projects).
Having a coordinate release across project would help, so long as the matching version number implies compatibility between components. To make this possible would require a certain amount of coordination across projects. The move to beta API for pipeline simplifies things but still we would need to:
Minor release would also have to be across projects.
An alternative solution could be to have a Tekton wide release version, stored perhaps in a dedicated repo. New releases in projects would trigger the creation of a new overall release.
This would remove the need for running a release on all project at the same point in time, but it would still require to set up the extra integration testing and cross-project release planning,
The text was updated successfully, but these errors were encountered: