Hi Hernán, On Thu, Jan 31, 2019 at 8:20 AM Hernán Morales Durand < hernan.mora...@gmail.com> wrote:
> I would like your advice on this: What's the effortless way to migrate > Github repository from Pharo 6 to Pharo 7? > Can you give us some more detail? Do you already have your project in github working for Pharo6? Or is it in Smalltalkhub and you are willing to move it to github? I'll assume the first below :) > > I thought in the following solutions: > > 1) In a Pharo 6 image modify my BaselineOf, add & push a new package > MyPackage-Pharo6, then load it into a Pharo 7 image, create > MyPackage-Pharo7 and port as needed. The same Metacello installation script > is preserved for all versions. > > 2) Tag repository as x.x in a Pharo 6 image, load my package & do port in > a Pharo 7 image and push to master. Previous Pharo 6 version could be > loaded referring to a tag (or branch maybe?) in the Metacello installation > script. > Well, it depends on what you want to provide as "support". - Do you want your package to keep working on both versions? - Do you want your new features to be available also in the old version? Case 1) Usually I try (if context agrees :) to keep a single branch. And I try that my project in that branch is compatible with both Pharo versions. Having a single branch if possible removes part of the bureaucracy of thinking about backports, patches, and so on... Releases are marked as tags, but they are shared between the different platforms. We were able to do it with Iceberg for a long time (and it is an example that relies on Spec, File stuff, FFI..). We have lost that compatibility in the last weeks because we made a fix for win64 that was not compatible with Pharo6, but I'm thinking in getting that compatibility back at lest for Iceberg 1.5.*. To keep a single branch compatible with many Pharo versions there is no magic: 1) we have a forward compatibility package to Pharo 7. The idea is that we write code for Pharo7 but in Pharo6 we can load a package with some extensions/additions that make it compatible with Pharo7. 2) we try to use compatible APIs. For example, we use FileSystem as much as possible. Another example is that Iceberg relies a lot in the Path class to manipulate the directory tree, and the nicest API of that class changed a lot so for simplicity we used the low level API that is a bit uglier and verbose, but compatible. Case 2) At the same time, just to set an example, we were thinking version 1.5.* was going to be the last iceberg version supported for Pharo6, so pharo7 and 8 were going to use 1.6.*. This means we will have two different versions running side by side. If we want to continue applying patches and critical bugfixes in the 1.5.* version, we should have two branches. Notice that here I'm assuming that my 1.5.* branch will move much more slowly than 1.6.*, since no real active development will be done with it. Probably other people can share their workflows. HTH, Guille > Any recommendations? Alternative paths? > > Cheers, > > Hernán > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
