[squeak-dev] Re: Packages, Packages, Packages
siguctua at gmail.com
Sun Dec 13 08:00:49 UTC 2009
2009/12/13 Miguel Cobá <miguel.coba at gmail.com>:
> On Sat, Dec 12, 2009 at 9:55 PM, David T. Lewis <lewis at mail.msen.com> wrote:
>> On Sat, Dec 12, 2009 at 06:01:55PM -0600, Miguel Cob? wrote:
>>> Why would you want to do that. 3.8 is dead, must be dead and should be kill.
>>> Let the past behind. Let your childs live their lives and go on. You
>>> can't oversee them *your* entire life. Squeak can't remain trying to
>>> get backwards compatibility forever. That way squeak will never make the
>>> foundation changes that needs.
>> This is complete utter bullshit. Failing to make a reasonable attempt
>> at backward compatibility is lazy and sloppy, nothing more.
>> Norton's third law of innovation:
>> Change is good, stupid is bad. Don't confuse the two.
>> Ok I feel better now. There are some rather significant forks based on
>> Squeak 3.8, and any package management system that fails to accomodate
>> this level of variation is in trouble.
> I think that that is the real problem with the solution provided by Keith.
> He tries to solve the problem for every fork. As if the forks care
> about its changes
> being compatible with the project they forked from.
> Keith mail after mail tried to convince people that a change must be/should be
> loaded in every fork existing and future. Utopia. That don't happens.
> If I choose Pharo and the software fix that I made works in pharo, my problem is
> solved. I couldn't care less if croquet, etoys, olpc or whatever can use it.
> The same they don't give a dime if their changes works on squeak.
> As an old discussion in this list pointed, the etoys project long ago
> forget squeak.
> Nevertheless, squeak is worried if their changes could somehow
> in squeak. :(
I think you misunderstanding the Keith's concept.
He wanted to provide a common denominator for all existing Squeak
forks, to make sure that some basic tools (MC and Installer) working
But its not gives any guarantees that your packaged code can be
installed and work in any of those environments.
This is something you need to determine by yourself.
Suppose, one developer made project that runs only in Pharo. Then
suppose that other developer wants to use it in Cobalt.
Now what he can do?
This is where it makes difference: if your project loading is based on
installer & LPF, one can make attempt to load the project in different
environment and see if it loads , or see where it breaks, and then
provide own custom installation script(s) ,
which does the job. But if your project installation meta-info is
based on Metacello , Gofer and <put you own favorite tool>, this makes
your project highly dependent from tools, which in own turn may
require porting to work in different environment.
But hey, MC & Installer already ported and ready to work at your disposal.
I love new and shiny stuff, but as a software developer i tend to care
about potential users of my code. And if my code can be loaded by
different forks, this means a broader audience of users of my project.
This is what all developers always want, hopefully.
And this is why i won't be using a packaging tool which works only in
some of the newest & latest squeak environment or its fork.
> SqueakMap fell apart when Squeak
>> 3.9 came along for this very reason, and we can reasonably expect that
>> future variations on Squeak will introduce similar incompatibilities.
>> This is a good thing, and our tools do need to be flexible enough to
>> support it.
> The only real example of code that works unmodified in newer hosting
> environment is
> in the zSeries Operating systems from IBM.
> They say (I don't know and maybe will never could verify because I
> don't have the millions
> to buy a mainframe from them) is that you can run software from the
> 60s in the 2010 machines
> without a single line modified. That is impressive but they charge
> accordingly also.
> We aren't so well funded nor have a real practical motivation to
> verify that every new version
> of squeak or pharo can run _every_ old version of _every_ package that
> some time ran on
> squeak. If someone want to keep using that old software they have two options:
> - remain part of the every day smaller group of users (and what that
> implies for bug fixing, etc)
> - load the old software in the new images and correct the errors found
> I choose number 2 because is what happend in the nature. The groups
> are stronger than the
Igor Stasenko AKA sig.
More information about the Squeak-dev