I believe the ReleaseBuilder process checks the "Changes" of every
package.  When we brought in WebClient, those extension methods became
no longer in the Network package (in "*WebClient-HTTP-override").  For
Changes to be smart enough it would have see if the "deleted" methods
were truly deleted, or just moved to another package as an "override"
and then..  not changed?  Hmm..

I think I'm gaining new respect for MC overrides that someone went to
such lengths for them.  Maybe there is something to them..

On Thu, Jul 2, 2015 at 4:53 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
>> On 02.07.2015, at 14:36, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Chris,
>>
>> On Jul 2, 2015, at 2:25 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>
>>>>> Do MC overrides actually somehow "reload" the code that was overridden
>>>>> when you unload the overriding code?
>>>>
>>>> Yes. It goes through the method history in the changes/sources file and loads the overridden definition.
>>>>
>>>>> If so, that is kind of amazing.
>>>>
>>>> Indeed. Although scary, too. Overrides are still evil, and should not be used unless really necessary.
>>>
>>> I wonder if it would work even after condenseSources.  That's been
>>> done for this release.
>>
>> Should do given that condenseSources now preserves history right?
>
> Yes, condenseSources specifically keeps the history of methods in *-override protocols.
>
> - Bert -
>
>
>
>
>
>