I've read in your other thread that you created separate repositories for the VirtualBox 5.2 and 6.0 major versions, which hopefully prevents a potential major version mismatch. But a minor version mismatch can also provide problems to the VirtualBox user (note that in VirtualBox 6.0.14
, the major version
and the minor version
Let's assume the user has VirtualBox 6.0.12 installed on the host, and the matching Guest Additions 6.0.12 installed in the guest. Now the newer VirtualBox minor version 6.0.14 is released. First, the user updates VirtualBox on the host to VirtualBox 6.0.14, and then starts the guest. The older Guest Additions 6.0.12 in the guest typically can be expected to not crash the guest, so that the user can update them now (without having had to deinstall them before updating VirtualBox on the host). But the user in general can not expect the older Guest Additions to work reliably with the newer VirtualBox version on the host. The same holds true for the opposite combination, which can occur when updating the Guest Additions first.
The reason behind that is that the combination of different minor versions between VirtualBox and the Guest Additions is probably not tested in development, with the exception of the suggested upgrade path (and even that will probably only be tested with successive minor versions). Additionally, there is no mechanism in place to guarantee a version match between the host and guest components of VirtualBox discussed here (add the VirtualBox Extension Pack for even greater complexity
). These are the reasons why the forum regulars typically suggest to install the Guest Additions accompanying the VirtualBox host software (by using the Insert Guest Additions CD image...
menu item of the VirtualBoxVM window).
I'd suggest to inform the user of your script to ensure using the Guest Additions minor version matching his VirtualBox installation on the host.