2:58 a.m.
Hi,
The existing flexibility helped us for sure. But if they can not
continue
because of technical reasons and because it is not sustainable then we do
not have a choice.
I think for Minishift upstream we still have the choice to download
respective baseline oc binary ( can not remember if we faced issue in the
past because of that).
I don't think this is the case. Take the case of the node name change between
cluster up in OpenShift 1.5 and 3.6. As the code stands right now, we could use
oc 1.5 to provision 1.5 (cluster up will run, but our post cluster up actions will
fail). We would have to start sprinkling conditional logic into our code based
on which OpenShift version you want to provision. Something we most likely should
avoid since we will just end up chasing the rabbit. Especially since we don't have
the testing in place to make sure everything stays backwards compatible.
I think if oc cluster up is dropping the capability to provision earlier versions
we should consider doing the same. In this model, once we use a new baseline (eg 3.7),
we do a major release of Minishift - 2.0.0. A major release is compatible with a given
version of OpenShift. If you want to continue to use 3.6 you will have to use Minishift
1.x. We might in this case have to sometimes release new 1.x versions to backport
important
bug fixes. Really this is the model most software is developed.
--Hardy