> > Ok, if I understand correctly, you are in favour of doing a break right
> > now. Go for option 2,
> > where even the default profile will move into a new location.
> Right. As the VM instance name change and the layout change will not be
> backward compatible change.
Unless we make no name and location change for the default. Since you are
playing the Minikube card. I am just playing devils advocate a bit.
> > As part of this, do you want to put anything in place to migrate existing
> > config, add-ons, etc
> > or leave it to the user. Effectively he should delete his $MINISHIFT_HOME
> > directory and start
> > over?
> I would leave it to user whether user want to move or wants to start fresh.
How? Just adding some docs somewhere or just a mention in the release annoucement?
Note, in the current form 'minishift update' does not take a major version change
into account. The user might jsut run 'minishift update' and by the time
the binary is released, there is no way back (in terms of a decision on what to do).
See also https://github.com/minishift/
> Also we need to communicate to the user that layout has changed hence we
> expect the user to do the changes
Again, that depends.
> > The move of the service command still gets a -1 from my side, but if the
> > majority things this
> > should be done, it would be a good opportunity to do so.
> I think we agreed that services is something common to both minikube and
> minishift. Also the user experience needs to be aligned. I think we should
> keep this similar to Minikube as we got user feedback on this.
The implementations have by now even more diverged. In terms of what they
display, how they display it and the options they support. So what is
better making this distinction clear by a command under the 'openshift' scope
or having seemingly aligned commands?