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