-
Notifications
You must be signed in to change notification settings - Fork 42
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
Conversation
Signed-off-by: Pritesh Bandi <[email protected]>
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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]>
#372 supersedes this PR |
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