In article <034301c3146d$41603240$6401a8c0 at hppav>,
Jim Benson <squeak-dev at lists.squeakfoundation.org> 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) ; 

The big plus as far as I can see is that you can write a stand-alone
desktop calculator that isn't ten megabytes in size.  Since I'm using
Squeak for stand-alone apps, that's _very_ useful for me.

>                                                                   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.

[and then a new version of Squeak introduces a bug that breaks Zurgle
and hilarity ensues]

The real problem is not with the packaging so much as that Squeak is a
moving target.  There are no guarantees of compatiblity between
versions and that really complicates things when you introduce
packages.  However, this lack of constraints lets Squeak evolve freely
so we don't really want to fix it in place.

So the current state has its plusses and minuses.

Of course, we can have it both ways.  Just do what the Linux folks are
doing and split the project into a stable branch and development
branch.  In particular:


	1) Squeak development continues as it always has, as a single big
	image with everything.  There is no guarantee that _anything_ will
	work between releases or even bug fix updates.  We call this the 
	development branch.


	2) Every year or two (or whenever the development branch reaches a
	major milestone) we take a snapshot of the development branch and
	call this the new stable branch.  

	All of the major subsystems get turned into SARs and experimental
	stuff gets put into SARs tagged as "alpha code".  There are no new
	updates to the core except for bug fixes and those are expected
	not to break compatiblity.


This won't be much extra work.  We just need someone to go through all
the bug fixes and see if it's relevant to their branch and the update
system will need to be able to handle the presence or absence of
certain key optional subsystems, but that seems to be most of it.

The problem with this, of course, is that it's effectively a fork and
forks (sometimes) divide the effort.  I don't think it's a problem in
this case, though, because code from one branch will be reasonably
easy to share with the other branch.  If we reach a point where this
isn't the case anymore, it just means that it's time to abandon the
current stable branch and start another.


>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.

See, I'd benefit enormously from something like that because I know
what's out there and can get it without any hard work.  Since I'm
usually trying to use Squeak to do stuff rather than hack on Squeak
itself, that's a huge help for me.

It's just like CPAN, only for Squeak.

But I can see why it's not useful for you--it depends on what you're
doing.  Hence, the stable branch idea.

Any thoughts?


                              --Chris


-- 
Chris Reuter                           http://www.csclub.uwaterloo.ca/~cgreuter
"Your Email Client does not support MIME encoding. Please upgrade to MIME-
 enabled Email Client (almost every modern Email Client is MIME-capable)."
               --From a random piece of spam