keith wrote:
>> Hi Folks,
>>
>> (reposted, in the hope of not being ignored)
>>
>> Package developers want their work to run on various Squeak versions 
>> and variants, without needing rewrite. Same for app developers.
>>
>> Base image builders want to be free of the need to provide backwards 
>> compatibility.
>>
>> This is what I suggest: A package assumes it can use a set of apis of 
>> the Squeak (/Pharo/Cuis/Etoys/Tweak/Cobalt/etc) environment. Those 
>> assumptions should be made explicit, in the form of tests. So, for 
>> example, for collections, some package developer might require the 
>> "Common Collection API tests" to pass. Then, if his package fails to 
>> run, let's say in Cuis, he would run the tests for the apis he needs. 
>> If some test fails, he could say "Cuis developers, you're not 
>> supporting api XXX", end expect them to fix the issue. But if no test 
>> fails, he needs to either modify his code so it doesn't use 
>> not-standarized apis, or he could negotiate with (all) base image 
>> developers the addition of a new api or use case to the test suite 
>> and the base images.
>
> Agreed wholeheartedly. 
>
> For this vision to have a chance, absolutely one thing is 100% 
> essential. SUnit must be common, between forks, and there must be some 
> way of flagging known exceptions for different target images. This is 
> something I attempted to add to SUnit in August 2006, in eagre 
> anticipation.

Why? All that is needed is to be able to run the same tests on all fork. 
That is asking a lot less than the SUnit package is exactly the same... 
Se Julian's recent message about Seaside and Grease. It even works 
across Smalltalk dialects.

>
> The second essential thing is for the package loading tools to also be 
> in common. That means Monticello (in my book, though probably not in 
> yours).

Why? This has nothing to do with how code is loaded into each 
environment. Package developers might choose between ChangeSets, 
Monticello, or possibly other options.

>
> However, most forks imho are keeping all of their libraries too close 
> to their chests.

This initiative (actually Grease) allows each fork to do exactly that, 
while having guaranteed compatibility. It is the best of both worlds.

>
> All efforts to change this, to move obvious loadable libraries like 
> SUnit, and MC out to be externally managed, have up to now failed. The 
> weakness of my attempts so far has been in the testing side of things. 
> (Matthew Fulmer is worth is weight in gold on that one)
>
> However Monticello is a complicated beast, I may have made 400 more 
> commits, merging 3 forks, but one or two bugs is all it takes to 
> reject the entire refactoring of the repositories code, the improved 
> more uniform ui implementation, the password manager, the dual change 
> sorter, the orphanage for out of order loading, public package info 
> properties for package managers, scripting of commits, memory analysis 
> per package, the atomic loader, cleanUp code, improved version 
> numbering, integrated Configurations, separated tests, default 
> packageinfo package types etc etc etc.

Those are package specific problems. I suggest getting in touch with 
Monticello developers to merge your changes.

>
> ...
>
> Correct me if I am wrong, but in my thinking if SUnit is forked, your 
> vision is pretty doomed.

As I said above, I see no reason for this.

> ...

Cheers,
Juan Vuletich