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

[Bert Freudenberg]

On Jan 24, 2007, at 15: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.  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.

Yep. On a related note, what you *absolutely* must not do in the base  
system is using Monticello overrides. It is tempting sometimes, but  
introduces so much problems it is not worth the hassle.

- Bert -