Hi Florin,
I think I understand what you're getting at now. You prefer the "last package loaded" strategy because it guarantees that at least one package will remain in exactly the intended state, and thus presumably work. Ok, fair enough. I think this argument is moot any way since:
- What's appropriate probably depends on the circumstances under which we're running. If I as a developer am loading a handful of packages to continue development, I don't mind risking a little breakage. But that's probably not the case if we're deploying for end users.
- The modules system shouldn't be dependent on any versioning tool, so we may want overrides (or some other strategy for dealing with multiply-defined methods) as a fall-back for when the versioning system isn't present.
- Given Dan's interest in security, we'll probably want some mechanism for preventing such method collisions from occurring at all. Classboxes, Islands or E probably has some solution that is more elegant than either overrides or versioning.
Part of a "project" may mean reverting a method to an existing, older version, reverting a class to an older version, reverting a package to an older version. This happens quite frequently when developing a patch. What does it mean for these components' history that you re-version them?
In MC2, if a developer reverts to an older version, the history will show that. A new version will be created, with identical "content" to the old version, but with metadata showing the intermediate version as an ancestor.
Colin