Hi Guillermo El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (< guillermopol...@gmail.com>) escribió:
> 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? > > Most of my packages are working on Pharo 6 already, and they are on 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? > Yes, ideally my package will work on both versions, Pharo 6 and Pharo 7. The first option was about splitting MyPackage into MyPackage-Common, MyPackage-Pharo6 and MyPackage-Pharo7 with corresponding methods/classes moved. > - Do you want your new features to be available also in the old version? > > I'm not really interested in backward compatibiilty. > 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. > > You're talking about branches but I've used branches for a different purpose (providing features for example). Wouldn't be more appropriate to use tags in this case? > 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.*. > > I will check those Baselines because I need to see examples of how does it work. > 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. > > Thank you Guillermo > 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 >
