[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.
Milan
>
> -Ralph
> _______________________________________________
> V3dot10 mailing list
> V3dot10 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/v3dot10
More information about the V3dot10
mailing list