Tekton Coordinated releases

[afrittoli]

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:

• have additional integration test to ensure components work together
• have a cross-project release planning meeting
• have more automation in place to produce releases

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,

[bobcatfish]

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:

1. Projects in tektoncd should be able to choose to release more or less frequently than each other; a project shouldn't have to hold up a release to wait for another project to catch up

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:

1. We could define specific LTS releases across projects that we coordinate and plan for at certain dates
2. We could define "distributions" of Tekton which are themselves versioned; e.g. version 0.1 of the Tekton distribution includes 0.15 of tekton pipelines, 0.17 of tekton dashboard, etc. , which are all known to work together (and maybe these are LTS releases?)

I think it's also worth identifying the dependencies between projects:

• Triggers depends on... no projects I think? (I think it used to be pipelines but not anymore?)
• Pipelines depends on no projects
• CLI depends on Triggers + Pipelines
• Dashboard depends on Triggers + Pipelines (does it depend on the CLI?)
• Operator depends on... Triggers + Pipelines?

A couple thoughts from this list:

• If we were to coordinate releases, it feels a bit like triggers + pipelines would make sense to release together - i wonder if it actually might be worth exploring treating them as one project together, even potentially going to the point of putting them in one repo, esp. as features like Actions and Notifications for Tekton pipeline#1740 have proposals that use both
• Is there a world where the CLI and Dashboard can support more than one Tekton version?

[bobcatfish]

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).

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.

[vdemeester]

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 operator that is able to install all. There is no discussion about velocity, it's defined (each and every 4 weeks, or whatever timeframe it is), you know you have to meet this to get a feature in a given release.

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).
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.

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 (tektoncd/operator, our openshift-pipelines operator), where the version of it, as of today, doesn't give any information of what is deployed (because it is may ship pipeline 0.12.x, triggers 0.5.x, dasbhoard 0.8.x, …) — see TektonCD operator versionning.

It is also the case for the cli by the way : as of today, tkn version has to list "component" version separately.

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.

Is there a world where the CLI and Dashboard can support more than one Tekton version?

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.

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?

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 tektoncd/operator) 🙃. The cli should definitely not have any "operation" knowledge itself (best scenario, it knows how to tell the operator to update, nothing more). The model where a tool update itself and has a lot of knowledge on himself works well for developers (and even…), but tends to be a pain in the *** as it goes against the system infrastructure (package manager, …) — but that's another topic.

[afrittoli]

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:

1. Projects in tektoncd should be able to choose to release more or less frequently than each other; a project shouldn't have to hold up a release to wait for another project to catch up

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:

1. We could define specific LTS releases across projects that we coordinate and plan for at certain dates

2. We could define "distributions" of Tekton which are themselves versioned; e.g. version 0.1 of the Tekton distribution includes 0.15 of tekton pipelines, 0.17 of tekton dashboard, etc. , which are all known to work together (and maybe these are LTS releases?)

I think it's also worth identifying the dependencies between projects:

* Triggers depends on... no projects I think? (I think it used to be pipelines but not anymore?)

There is a compatibility matrix between triggers and pipeline though.
When pipelines launched a new API version, triggers had to make updates for that.

* Pipelines depends on no projects

* CLI depends on Triggers + Pipelines

* Dashboard depends on Triggers + Pipelines (does it depend on the CLI?)

* Operator depends on... Triggers + Pipelines?

A couple thoughts from this list:

* If we were to coordinate releases, it feels a bit like triggers + pipelines would make sense to release together - i wonder if it actually might be worth exploring treating them as one project together, even potentially going to the point of putting them in one repo, esp. as features like [tektoncd/pipeline#1740](https://github.com/tektoncd/pipeline/issues/1740) have proposals that use both

* Is there a world where the CLI and Dashboard can support more than one Tekton version?

[afrittoli]

@wlynch related to discussion on version selection for the web site

[nikhil-thomas]

@bobcatfish

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 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).

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

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.

[vdemeester]

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

[tekton-robot]

@vdemeester: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/remove-lifecycle stale
/reopen

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.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

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.

[bobcatfish]

oh i didnt know this was closed! since it's on the roadmap i'd like to keep it open

/lifecycle frozen

[bendory]

The lack of well-coordinated versions resulted in multiple issues in Pipelines v0.43.x:

• Error: the API version in the data (tekton.dev/v1beta1) does not match the expected API version (tekton.dev/v1) cli#1837 + TektonHub Tasks apiversion v1beta1 not supported with new pipeline release v0.43.0 pipeline#5932 (same root cause)
• Pipelines v0.43.1 installation nondeterministically fails to update PipelineRun status with TaskRun statuses pipeline#5964
• Ensure Chains works with the v1 version of TaskRuns and PipelineRuns chains#665

We need to support forwards / backwards compatibility when we release components.