keith wrote:
>>>
>>> This is what happened in the case of ifNotNil: ifNotNilDo: merger.
>>
>>
>> I'm not sure what you're referring to.  The old method still exists, 
>> so no packages that you load can break from it.  What am I missing?
>
> A new package that does not know that ifNotNil: [ :value | ] is 
> invalid in 3.8 will not load or compile in 3.8. So you promote 
> compatibility and the ability to migrate, by fixing the OLD image, and 
> migrating the code to the new API there.
>
> The advantage of this being that your code base can move forward in 
> situ, and your packages dont have to use the old api, and you can 
> maintain one codebase for all squeak images ever.
>
>> You were probably just unaware that #ifNotNilDo: still existed.
>
> I know it still exists.
>
> Keith

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.

Building these suites is quite some work, mostly to be done by package 
developers. But it can easily point out responsibilities and duties. It 
frees package developers of needing to have a deep knowledge of various 
base images. And it frees base image developers from needing to know 
details about an unbounded set of external packages. Besides, it puts 
popular packages that everybody wants to support on equal footing with 
less-known packages. It also lets base image developers say "we support 
Common APIs xxx, yyy, zzz, etc.".

All what I say about base images could also apply to packages that offer 
services to other packages: There could also be test suites to specify 
their services, and allow users to switch versions of the packages they 
use knowing what to expect.

What do you think?

Cheers,
Juan Vuletich