On Wed, Mar 22, 2017 at 11:08 PM, David T. Lewis <lewis at mail.msen.com>
wrote:

> On Wed, Mar 22, 2017 at 02:39:41PM -0700, Eliot Miranda wrote:
> > On Wed, Mar 22, 2017 at 2:17 PM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >
> > > One temporary glitch is that the update to Kernel-eem.1067 is
> generating a
> > > merge
> > > request dialog. I'm not certain, but I think that this would go away
> with
> > > an
> > > additional update map to force update from Kernel-eem.1065 to
> > > Kernel-eem.1067.
> > >
> >
> > Damn, and I thought I'd figured out a way to get away with one update map
> > :-).  So how to I generate the intermediate map and what version number
> > should it receive?
> >
>
> I'm not sure I have this right, so hopefully someone else can confirm or
> correct me. But I think this is what is happening:
>
> - The update-eem.400 update map loads Kernel-eem.1065, which is the version
> immediately before the class hierarchy changes.
>
> - Kernel-eem.1066 (and any later package) has the package prefix that
> changes
> the class hierarchy. As of 1066, the changes have been made in the preamble
> but not yet committed, so the package is dirty after loading 1066.
>
> - Kernel-eem.1077 commits the actual changes. The package is dirty at this
> point, hence the merge dialog.
>
> Kernel-eem-1077 contains the prefix that makes the changes, and also the
> actual changes. So I am guessing that if we add update-xxx.401 and have it
> point directly to Kernel-eem.1077, then this would probably avoid the
> merge dialog. But I have not tried it so I am not sure.
>
> Dave
>

I did not get a merge dialog, so maybe all is fine?

Note that if Eliot had not put the migration code in a method, we wouldn't
even have needed an update map. With Tim Felgentreff I did this before (but
forgot to put in the inbox, sorry) and we only had a preamble like this in
the Kernel package:

---------- package preamble ----------
"CompiledMethod is too dangerous to change, Monticello won't do it for us"
(Smalltalk classNamed: 'CompiledCode') ifNil: [
(ByteArray variableByteSubclass: #CompiledCode
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Kernel-Methods') setFormat: CompiledMethod format.
CompiledMethod superclass: (Smalltalk at: #CompiledCode).
CompiledMethod class superclass: (Smalltalk at: #CompiledCode) class.
(Smalltalk at: #CompiledCode) classPool: CompiledMethod classPool.
CompiledMethod classPool: Dictionary new].

This way there's no need to have separate package versions adding the
script, introducing the preamble, loading the actual code, and removing the
script; it's just a single version.

(just mentioning this for future migrations, what Eliot committed works
fine)

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170323/4400de55/attachment.html>