Define Tekton LTS policy

[bobcatfish]

In the productivity working group a few weeks back we discussed what it would take to release more frequently.

One big blocker is that having a large gap between releases means that we are more likely to backport fixes to a previous release and have patch releases, which at the moment we really only do for the release before the current one.

If we were to release more frequently (imagine every 2 weeks or every week) previous releases wouldn't necessarily get fixes and to get the fixes, folks would have to adopt newer versions which would include new features, which they might want to do.

It seems like we might be at the point where it would make sense for us to define our policy more clearly and be more judicious about backporting fixes.

Strawman suggestion: we will backport bug fixes to releases which have occurred within the last 3 months of when the fix was made.

[ghost]

Strawman suggestion: we will backport bug fixes to releases which have occurred within the last 3 months of when the fix was made.

Responding to the strawman, this makes me very nervous but I might be misunderstanding the intended scheduling? The way I'm reading this right now: If we move to a weekly release cadence we'd have, minimum, 12 releases to backport fixes to at a given time (3 months = 12 weeks = 12 releases)? Even if our release process were cut to 30 minutes of work (right now a single release can span anything from a couple hours to a full day, depending on the patch and the state of the target version) that would still be 6 hours of concentrated work to backport into those 12 releases and we'd have some really tough problems around validating those 12 backports. Am I totally misunderstanding?

"LTS", to me, implies one blessed version that is given an extended lifetime. E.g. Ubuntu LTS defines a two-year cadence for LTS releases but they have a six-month cadence for their latest-and-greatests. Would this model work for Tekton? E.g. we could call version 1.0 an LTS that will receive bugfixes for a year or two and we'd also have weekly releases that offer new features and those same bugfixes (which are not backported anywhere but the current LTS).

I may be completely off-base here though?

[vdemeester]

If we move to a weekly release cadence we'd have, minimum, 12 releases to backport fixes to at a given time (3 months = 12 weeks = 12 releases)?

Backport fixes should only be on the LTS releases to reduce the workload. Doing backport fixes on weekly release would counter the benefit of doing those weekly release for sure.

"LTS", to me, implies one blessed version that is given an extended lifetime. E.g. Ubuntu LTS defines a two-year cadence for LTS releases but they have a six-month cadence for their latest-and-greatests. Would this model work for Tekton? E.g. we could call version 1.0 an LTS that will receive bugfixes for a year or two and we'd also have weekly releases that offer new features and those same bugfixes (which are not backported anywhere but the current LTS).

I may be completely off-base here though?

Indeed that could be the case. 1.0 would be a LTS and receive bugfixes for a year. During that year we could have another one (at 6month for ex.) to be re-considered as LTS, etc… The question are then :

• how often do we want to declare a LTS (roughtly, like Ubuntu does "after 3 releases", …) ? The timeframe between two LTS has to be really thought through : too often and it's a lot of burden for maintenance, not ofter enough and user will lag behind (and integrators too) — as my feeling is most integrators will release based on LTS, and most user will use LTS version as it is safer.
• when do we want to start doing that ?

[afrittoli]

We do have nightly "releases" today, but they have lower visibility than official releases because we do not publish release notes for them and do not have links to docs and examples on the main READMEs. I think a good way forward would be to improve the visibility and usability of our nightly release, adding release notes and setting up automated testing (we already do automated deployment every night). Making an official release would then mean blessing a specific nightly, and perhaps producing extra release notes since our last official release like we do today. I feel like having more frequent official release would require continuous integration between the various tekton projects (triggers, cli, dashboard), including testing of the version combinations that we want to support. I also share Scott's concern in terms of back-porting effort. Even if we automate more, back-porting may fail and require human merge conflict resolution. If we have to maintain 12 releases, that would mean a significant time of engineering time spent on that alone.

…

On Thu, 4 Jun 2020 at 15:03, Scott ***@***.***> wrote: Strawman suggestion: we will backport bug fixes to releases which have occurred within the last 3 months of when the fix was made. Responding to the strawman, this makes me very nervous but I might be misunderstanding the intended scheduling? The way I'm reading this right now: If we move to a weekly release cadence we'd have, minimum, 12 releases to backport fixes to at a given time (3 months = 12 weeks = 12 releases)? Even if our release process were cut to 30 minutes of work (right now a single release can span anything from a couple hours to a full day, depending on the patch and the state of the target version) that would still be 6 hours of concentrated work to backport into those 12 releases and we'd have some really tough problems around validating those 12 backports. Am I totally misunderstanding? "LTS", to me, implies one blessed version that is given an extended lifetime. E.g. Ubuntu LTS <https://wiki.ubuntu.com/LTS> defines a two-year cadence for LTS releases but they have a six-month cadence for their latest-and-greatests. Would this model work for Tekton? E.g. we could call version 1.0 an LTS that will receive bugfixes for a year or two and we'd also have weekly releases that offer new features and those same bugfixes (which are not backported anywhere but the current LTS). I may be completely off-base here though? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2746 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ2PKBDAJPG2LFVFR5PDCTRU6SURANCNFSM4NSBCNWA> .

[afrittoli]

Visibility of nightly releases: tektoncd/plumbing#407

[bobcatfish]

ah kk, I didn't realize that the practice was to designated certain releases only as LTS (though I think @dlorenc has tried to explain this to me before) - that makes this much easier :D

[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]

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]

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

[bobcatfish]

ooo this is a good one - i think im gonna add it to the draft roadmap for 2021. we haven't gotten a chance to look into this specifically but we've been talking about how to coordinate release across projects

/lifecycle frozen

[vdemeester]

@afrittoli I think this might be closeable ?

[afrittoli]

Yes, I think so - there may be a little work to be done in terms of testing tektoncd/plumbing#1288 - but the policy is there, and the releases too.