El jue, 09-09-2010 a las 21:02 +0200, Levente Uzonyi escribió: > On Thu, 9 Sep 2010, Stéphane Ducasse wrote: > > > Why are you so aggressive against us? > > I didn't mean to be aggressive, I just don't think your idea will work > well. > > > Now if you want status quo why do you even commit in squeak? > > I'm not against changes. > > > Now I'm not sure that this is the kind of > > I think the end of the sentence got lost somewhere. > > > > >>>> Isn't Grease dialect dependent by essence ? > >>>> If Pharo and Squeak diverge, then there will naturally be two versions > >>>> of Grease... > >>>> However, for these two messages, I think Pharo core should integrate > >>>> them and align with Squeak. The question is more whether you need to > >>>> distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... > >>> > >>> Probably else this means that Pharo and any system is bound to die because > >>> it does not change. > >> > >> The rapid changes and no-backwards-compatibility you prefer and advocate > >> are not essential for a Smalltalk system to "stay alive". Just look at > >> VSE, it didn't change in the last 10 years, and people are still using it. > >> In constrast Pharo 1.0 was considered abandonware four months after it's > >> release, which caused trouble for some users who didn't think that they'll > >> have to patch their code and rebuild their images to "get" updates/fixes. > > > > Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs > > closed. > > The versions are just a way to have milestones. Now there is no problem you > > think otherwise > > So if I have a Pharo 1.0 image with my code and I don't want to rebuild > the image, then how can I update it to 1.1?
You change the source for downloading updates from. Then in a workspace you fire up the updateFromServer code and voilá. This will apply the same patches that were applied to 1.0 since the freeze to reach the point where 1.1 is. Just the same as squeak. But given the multiple ways in that 1.1 is different that 1.0, if you do this in a production image of yours very likely your image will blow, because there won't be code that was in 1.0 and isn't in 1.1. That is the main reason that isn't a supported option. If enabled somehow (menu, code snippet, some wiki page instruction) a lot of users will blindly update a working image leaving them with a unfunctional one. As we don't have the time or the people to support incountable questions about why this happend, the best it to advise the users to put the code in monticello (a good thing, no matter the arguments about the monolithic, time-evolved image) and load their code in a new downloaded 1.1 image. If every works correctly then they can be sure that their package works on the new version. If not, well, they have still a running stable working image and can spend time making its package work in the new image. But this is effort for the user. No matter how good the developers of Pharo are, there is no possible way to guarantee that the update process will be flawless for every user and for each but the simplest cases. Cheers > > > Levente > > > > > Stef > > _______________________________________________ > > 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 -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
