[V3dot10] Case Study 1 (Answering Milan from needed Tool

Milan Zimmermann milan.zimmermann at sympatico.ca
Thu Jan 25 06:30:25 UTC 2007

On 2007 January 24 09:38, Ralph Johnson wrote:
> On 1/24/07, Jerome Peace <peace_the_dreamer at yahoo.com> wrote:
> > |I must be wrong, but I'd like to understand how such
> >
> > situation is dealt with
> >
> > |in Monticello.
> I followed back to the original posts.  That is a great story!
> In short, if Package1 requires a change to a method in Package2 then
> you should NOT move the method to Package2.  instead, you should make
> a new version of Package2 and Package1  requires that new version, not
> the old one.  

Yes thanks. So this has to be dealt with "manually" (by the author making new 
versions of both packages, or negotiating with the owner of any touched 
packages he does not own). 

> The problem is thiinking that "change" is the same as 
> "new version of a package".  Often changes cut across package
> boundaries.
> The worst is refactorings.  Suppose we decide to change the name of
> the #add: method.  This is easy to do in the refactoring browser.  it
> will require changine nearly every package, and if you use one of
> these new versions, you will want to use them all.  In general,
> version control systems do not deal well with changes to interfaces of
> packages.

I guess that's true. I wonder if there is a way to introspect packages and 
generate dependencies between them based on senders/receivers ... that info 
could be used both for version control potential problems like the one 
discussed and also for installer dependencies.

Thanks Jerome for the practical story and Ralph for the summary.


> -Ralph
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10

More information about the V3dot10 mailing list