ModuleDependency file approach

The representation of the module dependency records in the module dependency refset has changed (though when we say this it changed several years ago!), most notably by providing snapshot views with the last dependency rather than the valid dependencies. Changing values in the references in the full suggest interpreting it as a regular refset referencing unversioned components rather than versioned components.

In the original versioning design for refsets there were two flavours of references:
1) those that referenced components,
2) and those that referenced versioned components.

Since all but the module dependency refset were implementing the first case, versioned references were never documented appropriately. In versioned reference flavours, the assertion that version x1 of a module depends on version y1 of another module is still valid when in a new release a new assertion states that version x2 depends on version y2 of the other module, so both would get in the snapshot of valid versions. That was the reason earlier releases only published the "full" version of the module dependency refset accumulating valid states (because there were always new valid versions without invalidating the previous ones, then the full and the snapshot views were the same). The only case when the full and the snapshot would be different would be if a previously published dependency is corrected/inactivated.

More recently, the references are done against the module and not the versioned module, so the snapshot contains only the last version (even if the previous historical ones are still valid).

Extensions add records to the module dependency refset so the new practice would mean that the snapshot could only be used to compute dependencies for the last release.

The natural workaround of re-computing the snapshot from the full file instead of using the distributed one has also limitations as valid references are using the same memberUUID in the full view.

In addition to this, with respect to extensions and derivative products, there have been various approaches to this - either:

a)  including both moduleDependency records - thus calling out the dependency of each extension/derivative module to both the Core and Model Component modules (as in the International edition), or

b)  including only the one moduleDependency record - calling out the dependency for each extension/derivative module on the Core module ONLY, leaving the dependency of the Core on the Model Component module inferred from the International edition.

Finally, there have been inconsistencies in the application of the sourceEffectiveTime and targetEffectiveTime, which are set to the same value for most extensions/derivative products, yet some have the sourceEffectiveTime = the extension release effectiveTime, with the targetEffectiveTime = the dependent International edition.  The differential here has most likely come from our alignment of the derivative products with the International edition effectiveTimes, which has resulted in the dates being set to the same value.

We would like any thoughts and feedback on this please?