The problem doug is that it is unclear if all the features are needed and what is the status of the implementation. I do not know what are orphanage, scripts, upgrade upgrade, file.......
We just did not update to MC1.5 because we are idiot or blind. First we were focusing on something else and also when something is working for you then it is difficult to try something new and risky since it can stall the complete process. I do not even know what LFP is doing in our back. Now the key point is that if somebody in the pharo community stand up and take the **huge** and painful job to have a **real** look at MC1.5/1.6 and to be here as a fireman then there is a chance that we use it. Not just saying yes it works (which is already a challenge as I noticed it these days). Stef > Stéphane Ducasse wrote: >> I checked a bit but actualClassIn: in MC1.6 depends on >> MCMethodDefinition having theClass as instanceVariable. >> >> The results of this experience is clearly showing me that merging >> between fork is nearly impossible. >> I already lost some days on that issues and I think that we will stay >> with a slow MC for now. >> >> >> > Isn't the version loaded by the following code from my other mail the > already merged version of 1.5/1.6? (I believe that 1.6 is just 1.5 > with > atomic loading enabled) > > Preferences enable: #allowBlockArgumentAssignment. > Preferences disable: #raiseDepreciatedWarnings. > Installer upgrade upgrade. > Installer install: 'UpgradeMonticelloBootstrap'. > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
