Deprecate plugincheck in favor of plugincheck2

Question

Deprecate plugincheck in favor of plugincheck2

tolzhabayev opened this issue 2 years ago · 5 comments

Remove plugincheck from the readme and only keep plugincheck2
Show a message to migrate to plugincheck2 every time it's ran. Do not remove code yet.
Add a deprecation notice to the readme.md of the plugincheck pkg
Mark code as deprecated https://stackoverflow.com/questions/7849663/how-do-you-mark-code-as-deprecated-in-go
Search for usages of plugincheck in the wild:
- https://cs.github.com/?scopeName=All+repos&scope=&q=plugincheck+language%3AYAML#
- At least 14 plugins are currently using it

Answer 1 · 2023-01-05T13:03:50.000Z

@tolzhabayev since both of them are compatible can we start putting the plugincheck2 binary in place of plugincheck after a while?

Answer 2 · 2023-01-05T14:19:01.000Z

Are they really replaceable / a drop-in replacement?

Answer 3 · 2023-01-06T08:15:35.000Z

Are they really replaceable / a drop-in replacement?

The parameters are the same and the share the same configuration. I am not really sure why they were made as different projects. I'll ask around.

Answer 4 · 2023-01-09T08:33:58.000Z

Ideally we should end up with one project that is versioned (like our go sdk) - we need to figure out what is better:

Keep plugincheck and release a new version of it and deprecate plugincheck2
- Means we would have to migrate everyone and their CI's, etc. to plugincheck
Keep plugincheck2 and deprecate plugincheck which I would not change at all, also not place another binary into it - just leave as is
- Means we would have to keep plugincheck2 name forever and iterate on it using versioning (e.g. plugincheck2 version 0.312). Naming might be a bit confusing.
- Migrate everyone to use plugincheck2 which is at least already the case in plugin-tools and plugin CI pipelines generated from it

Answer 5 · 2023-01-09T08:44:25.000Z

@tolzhabayev we are almost in the second version. The only problem we have with deprecating plugincheck is that we can't control who is using it. We could delete the code for it and break the few places in some third party plugins that are using it and expect they realize they are using the wrong version.

I don't see option 1 as a viable option because it'd be considerable more effort to move everyone