Avi Bryant wrote:
>> If so, that allows contributors to distribute their new versions in  a 
>> form that specifies precisely how they need to be loaded, and  then a 
>> maintainer doesn't have to figure it out, and we don't have  to go 
>> back to change sets.
> 
> Ok, yes, that makes sense.
> 
> Although I wonder if it would be more intention revealing to create a  
> new, empty package named something like MorphicEtoysReorganization,  
> have it depend on both Morphic and Etoys, and commit that.  That way  
> you wouldn't have to clear the dependency later.  
It seems like what we want is "temporary" dependencies that hold for the 
loading of a specific version (and don't carry over to working copies 
derived from it). These would be useful for communicating boundary 
moving changes, but wouldn't have long term effects.

So suppose that I load M.2, and then a dependency wants to drag in E.2. 
The problem would be if the image of the person loading (the 
integrator), is at E.2', rather than the E.1 the change author expected. 
Then what we want is the integrator to have the opportunity to merge 
E.2, instead of loading it. In fact, it seems to me this might be a good 
default.

Seems to me that+one-shot dependencies would enable clean harvesting of 
such changes quite easily.

Daniel