Skip to content
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

chore: start using plugin-framework package #368

Closed
wants to merge 6 commits into from

Conversation

priteshbandi
Copy link
Contributor

@priteshbandi priteshbandi commented Dec 23, 2023

chore: start using plugin-framework package.

#372 supersedes this PR (which I have converted to draft)

Note: this PR has breaking changes but they are required in order to add support for plugin as library.

This PR depends on notaryproject/notation-plugin-framework-go#5

Copy link
Contributor

@shizhMSFT shizhMSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please consider starting moving to plugin framework package only after it reaches a stable version (i.e. v1.0.0).

)

var executor commander = &execCommander{} // for unit test

// GenericPlugin is the base requirement to be an plugin.
type GenericPlugin interface {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shall not remove any interfaces, types, or functions as notation-go is stable at v1.

Instead, consider this

type GenericPlugin = pluginframework.GenericPlugin

If the breaking change is not avoidable, you might need to consider notation-go/v2 but it would be another proposal to be discussed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same technique is applied when golang introduce the io/fs package as well as deprecate io/ioutil.

Examples can be found at https://pkg.go.dev/os#FileInfo

type FileInfo = fs.FileInfo

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try to add backward comparability support for interfaces but for other types and functions there would be breaking change. IMO the maintenance effort and code-change required to maintain backward comparability is not be worth it.
Lets discuss this in next community meeting, as suggested by you one way is to notation-go/v2


Please consider starting moving to plugin framework package only after it reaches a stable version (i.e. v1.0.0).

I was thinking of doing v1 for plugin framework package at the same time when we do next release for notation-go.

Signed-off-by: Pritesh Bandi <[email protected]>
Signed-off-by: Pritesh Bandi <[email protected]>
Signed-off-by: Pritesh Bandi <[email protected]>
Signed-off-by: Pritesh Bandi <[email protected]>
@priteshbandi
Copy link
Contributor Author

#372 supersedes this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants