[Pharo-users] Porting Github packages to Pharo 7

Hernán Morales Durand hernan.morales at gmail.com
Sat Feb 2 02:00:58 EST 2019


Yes I've concluded this is the "easiest" way.
Sadly it is hard to automate the porting.

Thank you Guille.


El jue., 31 ene. 2019 a las 6:49, Guillermo Polito (<
guillermopolito at gmail.com>) escribió:

> Well, I've said it somewhere in the mail, probably got lost in all my
> blablbla, so I'll summarize.
>
>  - I use tags to identify releases.
>  - A same release works in Pharo6 and Pharo7
>  - In the baseline I have defined some conditional package that is loaded
> in Pharo6 that provides compatibility from Pharo6 to Pharo7.
>      Of course, depending on the change you're doing you may want to have
> one package per platform besides the core.
>
> When I was talking about a single branch I was talking about the so-called
> master branch, not about creating a new branch (which was case 2)
>
> On Thu, Jan 31, 2019 at 10:29 AM Hernán Morales Durand <
> hernan.morales at gmail.com> wrote:
>
>> Hi Guillermo
>>
>> El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (<
>> guillermopolito at gmail.com>) escribió:
>>
>>> Hi Hernán,
>>>
>>> On Thu, Jan 31, 2019 at 8:20 AM Hernán Morales Durand <
>>> hernan.morales at 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
>>>
>>
>
> --
>
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190202/aa78a128/attachment-0001.html>


More information about the Pharo-users mailing list