-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
plugins: abstract base Go plugin for easier version upgrades #1537
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: estroz The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
85aedd5
to
0f88648
Compare
…ntations should be abstracted so they're easier to update. pkg/plugin/internal/v0: Init, CreateAPI, and CreateWebhook plugins in the state at which scaffolds/CLI was when plugins were implemented. These "base" plugins can be selectively used by versioned plugins. pkg/plugin/v0: Go plugin implementation v0.0. Used only for project version 2. pkg/plugin/v2: Go plugin implementation v2.x. Used for project versions 3-alpha and beyond. pkg/plugin/validation.go: add helpful error types.
0f88648
to
acb4d76
Compare
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.
Hi @estroz,
Could you please clarify what is the problem that are you trying to solve with this change? Sorry, but it is not clear to me why we need to rename v2
.
Also, IMO we should NOT rename or change the plugin v2 for v0
or base
. See :
- v1 -> Project layout v1
- v2 -> Project layout v2
- v3 -> Project layout v3 (where the plugins started to be in place )
To keep clear the concept adopted so far:
Note that in the case of the
v1
andv2
PROJECT version, a corresponding plugin version is implied and constant --v1
implies thego.kubebuilder.io/v1
plugin, and similarly forv2
. This is for legacy purposes -- no such implication is made with thev3
PROJECT version.
From @DirectXMan12 comment in #1528 (comment).
So, for me replace v2
for V0
will NOT make easier or more intuitive the understatement as described in #1537 (comment)
@camilamacedo86 package names reflect plugin version, not project version. Is this package structure not easier to create new plugin versions with than the current structure? Edit: in the past we had |
@estroz can you clarify versioning of the go plugin then a bit? I had originally envisioned that |
@estroz: PR needs rebase. 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. |
@DirectXMan12 that's how I see the pre-v3 relation as well. My goal here is to enable easy re-use of the frozen project version 2 plugin ( I also think we should consider not packaging plugins by project version, but given the above relation it might make some sense to continue doing so. We'd eventually have plugins |
Hi @estroz, I understand what you are trying to achieve. See that in #1498 the Also, see:
And then one day we will be able to remove v2, however, until there we need to make clear what is or not the code used by v2 projects since we cannot change it. Also, see that we have other places in the project, for example, the tests which follow the current structure and concepts adopted already:
Regards As you said in another comment/pr the V2 plugins is a very special scenario. So, I am OK to "duplicate" it for V3 now since it will not be repeated after that and then, the implementation will likely be different in the future. So, I still think that we should not move forward with. |
We can punt on this for now, and re-address when we start changing things after #1498. |
Because major and minor versions will be bumped often, plugin implementations should be abstracted so they're easier to update.
Init
,CreateAPI
, andCreateWebhook
plugins in the state at which scaffolds/CLI was when plugins were implemented. These "base" plugins can be selectively used by versioned plugins.