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 (< guillermopol...@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.mora...@gmail.com> wrote: > >> 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 >>> >> > > -- > > > > 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 >
