It's hard to converse with that Exchange webmail. Oh, Ok, here it goes. The one MCPackage _ One RPackage I'm Ok with, I made that working with my browser. But if this is the goal, then the current code is almost there and option 2) isn't needed ? A RPackage (the one with tags) clearly represent well what a MCPackage can be, bugs apart. (technically, it's a bit wider, since extension methods may belong to any protocol, not just the *PackageName : the AltBrowser consequently hides the extension name, which is interesting at the GUI level and works very well).
The only thing needed is to make sure than when Monticello says X belongs to MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B instead, and the reverse. There is a fault in the RPackage introduction there, which is that both RPackageOrganizer and Monticello are tracking system announcements, and giving them different meanings (and RPackage propagate its changes to Monticello). I am at around 10 Pharo images I had to scrap because the damage done by those bugs was beyond repair. When you say force people to have one class category, one RPackage, that I do not understand why. As stated above, you have everything to handle multiple class categories in a RPackage. Why add a RPackageSet layer above ? Why make the transition break that ? (RPackage is not, in my opinion, naming agnostic. The main bugs I found in RPackage are because someone believe it is, where it isn't) One thing I would suggest is : remove Monticello from system announcements. Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed (have a coherent view of the system). Thierry ________________________________________ De : [email protected] [[email protected]] de la part de Stéphane Ducasse [[email protected]] Date d'envoi : vendredi 7 septembre 2012 21:37 À : [email protected] Objet : Re: [Pharo-project] RPackage, Monticello and the removal of PackageInfo On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote: > Ok, > > It's good to know, because, for me, as I was / I am trying to track the > changes in RPackage for the past two weeks, it seemed that RPackage was > happily oscillating between 1 and 2, and, to add to the fun, backporting it's > instability by creating spurious packages in Monticello on the way. > > Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). > Should have stuck to PackageInfo :-(. you are not the only one. Benjamin too. Now we are fighting with it and this is just not for fun. > Is there a plan to have clear semantics of the different matches planned > (extension categories and sub categories, class category, package > sub-category) ? Yes Ideally we want one MCPackage - one RPackage + tags Nothing more (no class category, no package info). Now we should be able to remove class categories. But this does not work easily because everybody would have to rewrite configurationOf for their projects (since each categories would be turned into a package). So may be when versionner will be working we can add a behavior to migrate automatically configuration. So esteban will see if his idea is working which leads to a first class category and we can in a second period go more towards one MCPackage - one RPackage with tagged classes. > Monticello has already set a few conventions (not case sensitive, for > example) (and they are not respected by quite a few packages) and not a few > of the RPackage bugs are linked to it not respecting it (i.e. some methods of > package matching in RPackage are case sensitive, whereas they are not in > MCWorkingCopy) ? You forgot to add "crap in PackageOrganizer." So yes it would be good to clean all that. RPackage is totally agostic to naming conventions but we have to create them and support backward compatibility.
