Skip to content

Define compatibility policy for Go libs #2748

@bobcatfish

Description

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

Metadata

Metadata

Assignees

Labels

kind/miscCategorizes issue or PR as a miscellaneuous one.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.

Type

No type

Projects

Status

Done

Status

Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions