Porting Github packages to Pharo 7

I would like your advice on this: What's the effortless way to migrate Github repository from Pharo 6 to Pharo 7?

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.

Any recommendations? Alternative paths?

Cheers,

Hernán

Hi Hernán,

On Thu, Jan 31, 2019 at 8:20 AM Hernán Morales Durand <[hidden email]> 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 Web: http://guillep.github.io Phone: +33 06 52 70 66 13

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 <[hidden email]> wrote:

Hi Guillermo

El jue., 31 ene. 2019 a las 6:08, Guillermo Polito (<[hidden email]>) escribió:

Hi Hernán,

On Thu, Jan 31, 2019 at 8:20 AM Hernán Morales Durand <[hidden email]> 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 Web: 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 Web: http://guillep.github.io Phone: +33 06 52 70 66 13

Hernan,

> 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.

In my project, I migrated MyPackage into Pharo 7, and create
MyPackage-Pharo6 for compatibility.
Then updated BaselineOf to conditionally load MyPackage-Pharo6.
At some point, I will drop MyPackage-Pharo6 to make migration to Pharo 8
easier :-)

I haven't used branch or tag to support different platform versions.
I'd prefer branch over tag if I want to keep maintaining codes for older
platforms.
I'd like to hear how people are dealing with this issue, too.

Best Regards,
---
tomo



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html