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.