stepharo at netcourrier.com
Fri Jan 18 09:37:27 EST 2019
>> On my TODO is to make it stand-alone and provide is as a “compatibility transform”, too.
> I have to dig because I remember that I went over all the deprecation in Pharo 60 and started to look at the ones that I
> could “transformified” so that we get a nice package that rewrite more :)
>> So we can add it to methods that we want to keep for compatibility, but they will nevertheless transform the code automatically.
>> (this then might be disabled in production to not transform)
> Yes I like that I will look for my code.
Apparently I published under
MigratorPharo60 contains what I did for Pharo60
Migrator contains some of the Pharo70
Now I would like to understand how to organise it.
I have the impression that we should keep the one that can be transformed.
I do not think that we should go to Pharo50 because it is too old.
More information about the Pharo-dev