After the fix of bug #191657 it is possible for a user who has agreed to accept all updates to be left with some disabled modules in the installation which are incompatible with newly updated (enabled) modules, typically noticeable due to major release version increments. This is unacceptable since they will not be able to turn on those modules without updating them, nor update them without turning them on - a catch-22!
http://wiki.apidesign.org/wiki/Incremental_deployment#Easy_fix may be a workaround for a micro release where the number of updates is small and incompatibilities can be individually reviewed and controlled, but this would not be a realistic option if we wanted to do more significant updates.
One possible fix is to always update even a disabled module when it can be detected that the older version would not be compatible with other updates.
Another would be to make a note somehow in the user directory that the disabled module is due for an upgrade, and in any part of the AU GUI that would permit it to be enabled (directly or indirectly, incl. via FoD), do the upgrade first (assuming an UC is still available which lists the upgrade). Besides being lazier, this may be preferable because it ensures that important updates are honored even when there is no incompatibility visible at the module layer.
Another option would be to simply revert the fix of #191657, and solve the bugs it represents in some more direct way. (The comments in #191657 do not really describe what those bugs are.)
I consider this a defect. In 6.9 and before you could be assured that if you always agreed to accept updates, then whatever you had in your installation would in fact be up to date. That is no longer true - without your knowledge you can have obsolete and possibly unusable modules sitting around, and when you go to enable them there is no warning that anything is out of date except perhaps dependency errors coming from the module manager. That is a potentially important regression, and the cause of some priority bug in 7.0.1 (which I was unable to locate in BZ).
> One possible fix is to always update even a disabled module when it can be
> detected that the older version would not be compatible with other updates.
Probably preferred solution, if "it can be detected".
I am not sure of the details of AU manages proxy module infos, but it may work to run through disabled modules before the update checking for those which _could_ be enabled (i.e. problems.isEmpty()), and then simulate applying the update and check for any which now cannot.
I would hope AU already does this for enabled modules and rejects the update if it would break modules in use.
Uf, it seems as uneasy to solve this. I'm not sure I can fit NB7.1
No plan to fix it for now.
Just ran into this again. I have javahints 184.108.40.206.220.127.116.11.2 installed locally, but disabled since this build is not compatible with the current dev build's versions of other modules (it uses impl deps). 2.55.0.x is available on the dev UC, but I cannot update to it because of this bug.
The only workaround is to uninstall the plugin, restart, then go back to Plugin Manager and install it anew (and restart again since it specifies nbm.needs.restart=true).
I think the same problem would affect any AU module using spec.version.base to manage implementation dependencies on a module in the build.
*** Bug 232735 has been marked as a duplicate of this bug. ***
I think another solution would be to change the Enable function so that it prompts to update affected modules first. That way, you can still avoid pestering users with constant updates to disabled modules; if and when they ever decide to reënable them, they will be offered the newest versions.
*** Bug 221562 has been marked as a duplicate of this bug. ***