Gofer-dkh.105 or whichever later version predates the move of the instance variable would get Metacello back into a bootable form for all versions of Pharo.
I agree that for 1.0 a stable version of Gofer be chosen ... I'm trying to restrict the current Metacello changes to avoid significant API changes, but every time Gofer moves out from under me, I'm forced into making fundamental changes. Dale ----- "Lukas Renggli" <reng...@gmail.com> wrote: | >> | | >> After proceeding these warnings, I have a rollback: MNU | >> | | >> GoferPackageReference class>>name:repository: | >> | | > | >> | | > Can you evaluate | >> | | > | >> | | > [ Gofer gofer load ] | >> | | > on: Error | >> | | > do: [ :err | err retry ]. | >> | | > Gofer gofer recompile. | >> | | > | >> | | > ? I don't have any senders of #name:repository: to | >> | | > GoferPackageReference. | | We can remove the deprecated warnings, but that will not solve the | real problem. Metacello is using some internal parts of Gofer that | had | to be changed to properly support fetch/push operations on multiple | repositories. | | People have to stick with an old version of Gofer/Monticello. That's | the same as with Pharo 1.1: Do not use the latest one. | | Lukas | | -- | Lukas Renggli | http://www.lukas-renggli.ch | | _______________________________________________ | Pharo-project mailing list | Pharo-project@lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
