Define compatibility policy for Go libs

[bobcatfish]

Expected Behavior

We try to minimize the impact of changes to our Go libs on other projects that are using them, for example in #2717 (comment) when @pritidesai noted the impact of that change on the CLI.

It would make sense to have a clear policy around:

• How to make backwards incompatible changes to the libs and what expectations should be around this for users of the libs
• What is and is not part of the lib (people can currently import anything from tektoncd/pipeline except the builders in internal)

Actual Behavior

We have our API compatibility policy outlined in https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md but it does not currently include our client libs.

Additional Info

If we can identify which parts of the code we think it is reasonable for folks to import and use as libs, we can move the rest into internal and that would make it very clear which code you can change without impacting other projects.

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

[pritidesai]

/remove-lifecycle stale
Defining such policy is crucial as we are approaching v1.

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

[vdemeester]

/lifecycle frozen

[wlynch]

/reopen

Wanted to re-raise this issue for discussion (especially as we near v1) - I think it would be useful to apply deprecation policies to client libraries.

For Go in particular, a breaking change to a minor version best case means that tools like dependabot can break and manual intervention is needed by humans to upgrade, and worst case means that tools build on top of Tekton may be incompatible with each other (i.e. if 2 separate libraries depend on different client versions, minimal version selection may force the selection of a non-compatible dependency). We can still make rapid changes to alpha APIs / clients, but for stable APIs it would be great to have more guarantees around stability.

[tekton-robot]

@wlynch: Reopened this issue.

In response to this:

/reopen

Wanted to re-raise this issue for discussion (especially as we near v1) - I think it would be useful to apply deprecation policies to client libraries.

For Go in particular, a breaking change to a minor version best case means that tools like dependabot can break and manual intervention is needed by humans to upgrade, and worst case means that tools build on top of Tekton may be incompatible with each other (i.e. if 2 separate libraries depend on different client versions, minimal version selection may force the selection of a non-compatible dependency). We can still make rapid changes to alpha APIs / clients, but for stable APIs it would be great to have more guarantees around stability.

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.

[dibyom]

Planning to incorporate this in #5633