Why do you think Squeak changing wouldn't break Zurgle?
Why do you think Zurgle wouldn't interact badly with StarBrowser?

Only reasons you're noticing that problem now is that SM makes it so
much easier for people to use your code, you're getting more feedback.
Since it makes it easy to load that AND other tools, some people
actually try both together. 

The reality is the same reality - bits rot, complex software needs to be
maintained. 

SM means that you're doing the same things for a lot more benefit - more
people enjoying the loveliness of your changes. 

Modularization will one day means you'll need to do less work, and you
work will be worth morebecause of cleaner interfaces. As in all those
package that show up in the open menu, and magically don't remove one
another when two are loaded :-)

Daniel

Jim Benson <jb at speed.net> wrote:
> Stephen,
> 
> I agree with the SqueakMap stuff. However, another part of the 'packaging'
> effort is refactoring the image and making large chunks of the image
> 'unloadable'. For me, that's problematic (ok, I think it sucks) ; what
> happens is that you end up with a whole lot of different configurations of
> Squeak. I'll give you a example:
> 
> - I write a package, let's call it Zurgle.
> - By request, I place it in a SAR package on SqueakMap.
> - Let's say that going from 3.2 to 3.4 a bug is introduced,. For the sake of
> argument, let's say it introduces a problem in 32-bit color management. This
> manifests itself as making IconicButtons invisible, and confuses FlapMorphs
> in their layout when different fonts are assignd. Both problems in the stock
> image.
> - By coincidence, let's say that Zurgle happens to try to load itself in
> 32-bit color. People who download the SAR complain, and the 'reliability' of
> the Zurgle package is questioned. User downloads Zurgle, it don't work.
> - As another coincidence, let's say we have an image upgrade going from 3.4
> to 3.5. (Zurgle package is still marked as 3.4 on SqueakMap, so it doesn't
> show up under packages).
> - User does magic incantation, figures out the 'show all versions' deally
> and tries to load the Zurgle SAR.
> - Squeak starts barking, "server not responding" error, though you can use
> the download menu item to download the SAR.
> -- This is a SqueakMap bug
> - There's another problem;  compatibility with the StarBrowser package.
> StarBrowser needs a little magic incantation to work in harmony with the
> zurg.
> 
> As with any new image release, there are some problems. At the end of the
> day, Zurgle comes out looking unusable, with which I have to agree.
> Regardless of who, what, when, where or why it doesn't work. The feedback I
> get, "Zurgle isn't a very reliable package". OK.
> 
> So, just like in the old days, I would hunt up the bugs and submit fixes (or
> more likely whine loudly and the amazing Ned would magically fix them :-)
> Submit them to the list with the appropriate tag. But here's the rub. Once
> people start splitting the core image up, you can bet that whole silly
> dependencies graph thing rears it's ugly head. To run this package you need
> version 1.2 of this and 3.2 of that and 2.7 of the other thing. I'm not
> close to smart enough to figure all that out. I couldn't even get my simple
> package to work going from 3.2 to 3.5 when virtually no changes were
> introduced within the monolithic image.
> 
> At the end of the day, what did all of the packaging stuff buy me? I'm sure
> that there are benefits, I just can't think of any.
> 
> Jim
> 
> 
> 
> > Jim Benson wrote:
> >
> > >Bob Arning wrote:
> > >
> > >
> > >>My dislike for the packagizing effort stems from:
> > >>- it does not solve any problem that I face now or forsee facing in the
> > >>
> > >>
> > >near future
> > >
> > >My sentiments exactly.
> > >
> > >Jim Benson
> > >
> >
> > I sort of look at SqueakMap as a kind of Google for Squeak stuff.  It
> > makes it very easy to find and install Squeak goodies that people create
> > that are not included in the base image.  For me, that's the most
> > important thing that SqueakMap does.  The packaging effort is nothing
> > more than a refactoring effort.
> >
> > - Stephen
> >
> >
> >