Anthony Anton <agantoniii at earthlink.net> wrote:
> Out of a combination of shear laziness and not wanting to be lobbing 
> "stuff's not working" messages to the list I haven't been keeping a 
> log of the specifics for well over a couple of months since finding 
> that the "from scratch" method gets me to usable results. The Squeak 
> Community has and is doing a tremendous job and I have been very shy 
> about wasting other people's time.

A fine answer to the problem of upgrade errors is to treat them as bugs.
 Really, it should work to upgrade any 3.7-ready package on SqueakMap to
a newer 3.7-ready package.  Whenever it doesn't work, the maintainer
should be informed.

Thus, I don't see the need for better installation and upgrading tools,
but instead would focus on bug tracking and organization.  In
particular:

	1. There should be such a thing as 3.7-ready packages again.  There's
no reason to continue the current sloppiness of marking all  packages as
available even if the maintainer hasn't touched them for over a year. 
This was posted about before, but unfortunately interest seems to have
died down.  It would be very nice if the user saw a completely separate
package map depending on what Squeak they are looking at it from.
	
	2. There should be a handy way to report bugs to individual packages. 
But even without special bug-tracking tools, it is perfectly possible to
look up the author's email and drop them a message.
	
	3. Possibly, errors during installation should pop up an offer to email
a bug report automatically.  Not all upgrade errors happen during the
upgrade itself, but some do.
	
	
So that's my suggestion as a way forward.  And actually, I believe it's
a way we're heading anyway.

Keep in mind that one criterion of a "stable" release could be that you
can install and uninstall any packages on the map so long as you honor
their dependencies.  Packages that are not even installable would simply
be removed from any "stable" area of SqueakMap.

-Lex