Doug Way <dway at mailcan.com> wrote:
> Lex Spoon wrote:
> 
> >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.
> >
> 
> Also a big part of the problem here is managing the maintenance of some 
> of these packages.  Some packages aren't actively maintained, but are 
> still used, and for these packages we need to have co-maintainers added 
> who might be able to keep things working.

Absolutely.  If a package is so ill maintained that the
supported-versions field  does not get updated, then it really needs a
new maintainer.  Squeak versions do not come out all that often, not
nearly as often as real bugs are turned up that need to be fixed.

I expect the problem is not overburdened maintainers, however.  Instead,
they forget about the old packages they have posted and never become
aware of the problem.  If the maintainers get reports of installation
and upgrade problems, then that's pretty much all we need to happen.



> 
> Yes.  Although I've been thinking that a better solution to this might 
> be to have the SMLoader bring up a confirmation dialog if you try to 
> install a package which is not listed as being compatible with your 
> current image.  For example:
> 

It is a losing proposition to try and mix packages from different
versions.  I don't think we should support it at all.  Packages only
make sense within a particular pool of other packages.  Throw a
fresh-water package into a salt-water ocean and it will die.

I really think we should just commit to having a different pool of
packages available for each version stream of Squeak.  We seem to need
to anyway, and doing it solves a lot of problems.

Doing so does require that we address the issue of inactive maintainers.
 A simple solution to this is for new maintainers to simply repackage
inactive packages under new names.  This is all open source, right?  If
package Foo stopped maintenance at Squeak 3.5, then anyone is free to
make a NetFoo package that is maintained with different people and which
works in 3.7.  If and when the Foo maintainer comes back to life, they
can integrate the changes from NetFoo and move on.  Or if the maintainer
stays idle, everyone can switch over to NetFoo.  This is my prefered
solution.


Another approach to dealing with inactive maintainers is to have some
sort of non-maintainer upload.  These are awkward to deal with, however.
 For example, the maintainer can come back to life, upload *their*
version of the package, and *break* again the bugs  that were fixed in
the non-maintainer upload.



goran.krampe at bluefish.se wrote:
> Well, the technical part has "been handled" IMHO - meaning that if
> people migrate over to using Monticello - which will happen more and
> more, especially since the standard packages most surely will use that
> format - then upgrades will be technically "sound".

Monticello is good but it is neither necessary nor sufficient for
solving upgrade problems.  It may well help, but let's not overstate the
case.


To see that Monticello is not necessary, consider that Squeak has gone
through thousands up upgrades at this point by using changeset format. 
Clearly it is possible to make do with changesets!

To see that MC is not sufficient, consider the issue of existing
instances in the image.  That's a common place to get bitten by
upgrades, but MC doesn't help with it.  As one example, LargeLists
changes the definition of PluggableListMorph, and typically there are
instances of PluggableListMorph active in whatever image it is loaded
in.  Thus, LargeLists must be careful to handle the upgrade transition. 
In fact there is some careful code in LargeLists to allow for this, and
no format would have made this work automatically.  The maintainer
fundamentally needs to be involved in decisions about how to upgrade
existing instances to new ones.  LargeLists uses changesets, not that it
matters one way or the other.


To solve the upgrades issue we should focus less on technical measures,
and more on lines of communication.  In particular, we really need to
make sure that maintainers are made aware when there are installation or
upgrade problems.  The idea of an "email maintainer" menu item in SM
Browser sounds simple and effective to this end.


-Lex