-
Notifications
You must be signed in to change notification settings - Fork 371
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
Alternative branching for custom indexes instead default branch #832
Comments
I added a solution with respect to my proposal #833. Appending branch name with |
it seems a little strange to me to handle this with different versions of the index. homebrew handles this by allowing versioned formulae in their main tap. i dont know off the top of my head if that is already possible with krew (i forget exactly what parts of the plugin spec are used to setup the binary installed in i think your implementation makes sense for solving this by versioning the index (as long as that clone command properly sets |
@chriskim06 thanks for your comments. I had a similar discussion on Slack with @ahmetb and he also had some concerns about supporting this in terms of maintainability and narrow audience. I'm closing my PR due to this, I'll keep issue for a while in case someone else also need this; |
I incorrectly closed issue :). Sorry for noise. |
/close |
Currently, when user adds a custom index, Krew clones this repository from the default branch statically. Since distributions of most of plugins are managed in these default branches(master, main, etc.), it works without problem.
On the other hand, this mechanism does not work for the plugins that using branching strategy per release. For a specific cluster version, plugin maintainers want to force users to use only specific major version(and auto updates of minor versions via Krew). For example, for my cluster v1.2.X, user should use 1.2.X which means that user should add Krew custom index only being encompassed by this branch and I'll continue working on master branch for the next release cycle, v2.0.X without impacting v1.2.X releases.
This feature proposal may look very specific, but this provides an option to plugin maintainers about just cutting a branch for a specific release and continue working on new features on their master. And old clients can still use it safely because auto upgrade will not upgrade to a very latest version which is apparently not compatible.
As maintainers of Krew, you know the use cases and features requests better than me and if my proposal still looks very exception, feel free to close this issue.
/kind proposal
The text was updated successfully, but these errors were encountered: