Is your feature request related to a problem? Please describe
There are tools like kubectl (or clusterctl) which call APIs which are constantly evolving.
E. g. you may need to maintain different installations of Kubernetes which are not necessarily at the same version level via kubectl.
Taking kubectl as an example, at a certain point in time you might want on your working laptop the following lines available:
- kubectl-1.33 (e.g. version 1.33.10)
- kubectl-1.34 (e.g. version 1.34.6)
- kubectl-1.35 (e.g. version 1.35.3)
Unfortunately, this is currently not properly supported by WakeMeOps:
- As soon as version 1.36.0 enters the stage, patch updates to older lines are not considered any longer.
- While it would be possible to provide dedicated blueprints for each line, there is no way to have the first two version digits be fixed, and a newly appearing line would be ignored.
Is there something which can be done about that?
Describe the proposed solution
A rough idea:
- Equip blueprints with a setting enumerating version lines to support (
1.33, 1.34, etc.).
- Update also searches for new version lines.
- The actual version line is available as parameter during build and can hence be included into the name of the installed binary.
Is your feature request related to a problem? Please describe
There are tools like kubectl (or clusterctl) which call APIs which are constantly evolving.
E. g. you may need to maintain different installations of Kubernetes which are not necessarily at the same version level via kubectl.
Taking kubectl as an example, at a certain point in time you might want on your working laptop the following lines available:
Unfortunately, this is currently not properly supported by WakeMeOps:
Is there something which can be done about that?
Describe the proposed solution
A rough idea:
1.33,1.34, etc.).