On Fri, Aug 11, 2017 at 1:28 PM, Hardy Ferentschik <hardy(a)ferentschik.de>
> 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
cluster up in OpenShift 1.5 and 3.6. As the code stands right now, we
oc 1.5 to provision 1.5 (cluster up will run, but our post cluster up
fail). We would have to start sprinkling conditional logic into our code
on which OpenShift version you want to provision. Something we most likely
avoid since we will just end up chasing the rabbit. Especially since we
the testing in place to make sure everything stays backwards compatible.
True. This is a nightmare.
I think if oc cluster up is dropping the capability to provision earlier
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
1.x. We might in this case have to sometimes release new 1.x versions to
bug fixes. Really this is the model most software is developed.
How many branches we should support? e.g. when origin 3.8 will get released
users would need 3.8, 3.7 3.6 and even 1.5 versions of OpenShift. Back
porting bug fixes are fine but the issue is users would want to use newer
features of Minishift with older version of OpenShift Origin.
I need to look in to the code to see how much code we have maintain if we
want to support multiple versions before I comment. But giving users
ability to change versions will add a lot of value when cluster up is not
doing that. Also I understand that it can be a rabbit hole.