<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-02-14 10:04 GMT+01:00 Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_quote"><div><div class="m_-411068846337827352h5"><div dir="auto">On Tue 13. Feb 2018 at 20:38, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Eliot,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <span><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<span><br>
<br>
> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:<br>
><br>
> This one I'm going to need some help on, having never done this before (obviously).<br>
><br>
> -----<br>
> When and How to change the trunk update configuration:<br>
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)<br>
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)<br>
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration<br>
<br>
</span>That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.<br>
<div class="m_-411068846337827352m_-7747667307687975235m_-7658853103690707516HOEnZb"><div class="m_-411068846337827352m_-7747667307687975235m_-7658853103690707516h5"><br></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.). </div><div><br></div><div>Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?</div><div><br></div><div>-cbc</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><div dir="auto">IMHO we have way too many config maps already.</div><div dir="auto"><br></div><div dir="auto">We don't need any config maps even for moving methods between packages. </div><div dir="auto"><br></div><div dir="auto">The only time when you actually need an explicit config map is when you are doing open-heart surgery on the kernel.</div><div dir="auto"><br></div><div dir="auto">This is because besides the explicit config maps, the implicit map loaded at the end of the updater usually takes care of everything. It is created on the fly by taking the last published config map and updating it with the latest packages from trunk.</div><div dir="auto"><br></div><div dir="auto">Creating unnecessary config maps just slows down the update process.</div><span class="m_-411068846337827352HOEnZb"><font color="#888888"><div dir="auto"><br></div><div dir="auto">- Bert - </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div>
</blockquote></font></span></div></div>
<br><br></blockquote><div>+1<br><br></div>Other cases: renaming a class is not traced by MC version control<br></div><div class="gmail_quote">This is seen as addition of a class NewName and deletion of class OldName.<br></div><div class="gmail_quote">If there are instances of OldName that we want to migrate, then we have to use some preamble/postscript<br></div><div class="gmail_quote">1) publish NewName, use NewName in client code, and becomeForward: OldName allInstances in postscript<br></div><div class="gmail_quote">2) Remove OldName and suppress postscript<br><br></div><div class="gmail_quote">That means at least one update map entry for 1)<br></div><div class="gmail_quote">Note that if ever a block refering to OldName is forked, then the process has to be restarted with some surgery...<br><br></div><div class="gmail_quote">An alternative would be to script the class rename in some preamble...<br></div><br></div></div>