[V3dot10] Case Study 1 (Answering Milan from needed Tool
bert at freudenbergs.de
Wed Jan 24 14:58:19 UTC 2007
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
> 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
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 -
More information about the V3dot10