Procesos de actualización de la .image [Archivo adjunto 1]

> **
>
>  [Más abajo se incluyen archivos adjuntos <#13547e7c6b28f004_TopText> de
> Edgar J. De Cleene]
>
> Gentes:
>
> Los procesos de incorporación de código externo a una .image en Squeak,
> Pharo y sus forks,  tradicionales son:
>
> *FileIn de un archivo .st
> *
> Se puede incorporar desde un método , una clase , a toda una categoria,
>
> Idealmente, debería usarse para incorporar a la .image un único metodo
>
> FileIn de un archivo.cs
>
> Se puede organizar un Change Set de forma tal que contenga cambios a
> clases no relacionadas.
> Esta fue antiguamente la forma de incorporar updates y estos updates en
> forma de .cs numerados se ubicaban en un ftp externo desde donde se bajaban
> e instalaban,
> Se puede tener en forma local , dentro de la carpeta, folder, directorio
> etc correspondiente al FileDirectory default en una carpeta ‘updates’.
> Según uno de mis masters , Juan Vuletichm esta es la única forma en que se
> tendría que trabajar.
>
> Mientras unicamente existieron .cs para actualizar , el proceso fue fluido
> y no conozco de casos en que se haya interrumpido.
>
> En la release 3.9 Stephane Ducasse y Marcus Denker incorporaron el
> concepto de actualizar con paquetes Monticello.
> Como era la primera vez que se intentaba, el proceso no era ni alpha y
> genero todo tipo de inconvenientes e incomprensión general con estos
> adelantados a su tiempo.
> Algo que heredamos fue el acostumbrar a la comunidad a bajar imagenes
> completas.
>
> En el 3.10 le propuse a Ralph volver a los .cs, pero Stephanne lo
> convencio que habia que continuar puliendo ese proceso.
>
> Modestamente, invente la forma de hacer que los .mcz se buscaran desde sus
> repositorios e incorporaran a la imagen creando un .cs.
> Tambien volvi a usar el ReleaseBuilder para todo este proceso, de manera
> que todo quede documentado.
>
> Este proceso fue pulido por Andreas Raab y adoptado hasta el dia de hoy,
> donde la release en proceso usa el repositorio trunk.
>
> Hablo de esto porque como consecuencia de la destrucción del Pier que
> supimos tener hice hasta ahora.
>
> Crear una version local de lo que habia antes de la desgracia.
> Esta version está alojada en MillenaryFalcon con sus 200+ mega.
>
> Rescate un SqueakLight3Pier que encontre en NikolaiTesla y ya hace casi
> dos dias que se está actualizando.
>
> Un problema es que se corta el proceso cuando encuentra un Merge que el
> usuario debe decidir.
> Tengo que trabajar en resolver eso cuando ocurra de nuevo, contaré la
> experiencia.
> Una de mis muchas modificaciones , que no están el la versión oficial , es
> forzar a que cada CompiledMethod tenga author.
> Esto a su vez permite
>
> Asegurarse que ciertos metodos esten en la imagen objetivo
> Utilities methodsWithInitials: 'edc' inClass: Object . " hacer inspect "
>
> Utilities methodsWithInitials: 'edc' inPackage: 'Monticello'
>
> Planeo extender este concepto para que en caso de un Merge se fije si el
> método que va a cambiar pertenece al autor de la version anterior.
> En mi caso, si existe versión anterior con iniciales ‘edc’, elegir esto
> para el Merge.
>
> Feedback ?
>
> Edgar
>  
>