Henrik wrote:

> > The real question is: what is the basis for the
> > deltas?  If you think of a module "A" with three versions (1, 2 and 
> > 3), the evolution of this package looks like:
> > 
> > A.v1 -> A.v2 -> A.v3
> > 
> > These three versions repesent a snapshot in time of the 
> state of this 
> > module.  The states in between these three versions are 
> (for whatever
> > reason) not important enough to capture.
> 
> It's unclear to me what you are after here. Can you clarify?

What I mean is that versions of a module represent a snapshot in time of
the state of the module.  In theory, you could have a continuous stream
of versions that capture each and every small change made to the module
from the very first class definition.  But, that is clearly not
workable.  So, the question is, what is the reason we take these
snapshots in time, and how to we decide when it's desirable to have a
snapshot?  The obvious answer is that we are taking a snapshot so that
we can capture a viable working version of our module, so that others
can use the module for other work, so that we can distribute the module,
so that we can continue forward with experimental development and have a
working version captured in case we need to revert back to it, etc.

So, we must allow different versions of the same module to be
co-resident and active in the system.  We must also allow modules under
development to be resident and active in the system even though they may
not have been "versioned" by outputting them to a module file.  I
believe that you do allow for these things.      

> > The question is: how to I
> > arrive at the v3 state?  I could load three delta modules 
> that take me 
> > sequentially through each state to arrive at v3, or I could 
> load one 
> > delta module that takes me all the way to v3.
> 
> You could do either. It should be possible to load & apply 
> all three deltas in one swoop.

I agree.  The important thing is that if we recognize that all modules
represent deltas to the system, the question is, what is the basis for
the module, and what is the target state?  In your non-delta modules,
the basis may be nothing, and the target is A.v1.  I could have another
module where the basis is A.v2 and the target A.v3.  I could have yet a
third module where the basis is A.v1 and the target A.v3 (skipping
through A.v2).  If I have A.v1, A.v2, and A.v3 resident in my system, I
should be able to generate modules for any of these combinations.
Perhaps the notion of a module should be considered separately from the
physical file containing the deltas needed to apply the module to a
system.

I just hope it gets into the update stream soon.

- Stephen