Göran Hultgren wrote:
> Hi all!
> 
> Quoting Stephan Rudlof <sr at evolgo.de>:
> 
>>goran.hultgren at bluefish.se wrote:
>>
>>>Hi Daniel and all!
>>>
>>
>><...>
>>
>>>Should we add a field (optional) for each package telling the minimal
>>>update level for it to work? If it is entered in the package and the
>>>client image is below that threshold we can throw up a simple warning
>>
>>to
>>
>>>the user to go ahead on his/her own risk.
>>
>>But not a warning too harsh:
>>If I'm releasing a package I'm sure that it works with my current
>>update
>>level. Normally it should also work with a previous update level, but
>>I'm
>>not willingly to test with older versions (which?, how far back?).
> 
> 
> Yes, that is probably a common scenario. Note also that each package is marked
> with at least one (or more) of the mandatory categories in the category "Squeak
> versions". (2.8, 3.1, 3.2 etc) And that should be used as the primary guide for
> compatibility IMHO but still - this little warning could be nice to have, it
> would at least make the user aware of the fact that unexpected glitches may appear.
> 
> 
>>Triggered by this I have an idea: what about a hint to the user to
>>update to
>>the current version before loading something with a higher update
>>level?
> 
> 
> Yes, that is definitely something we should "tell" the user at that point.
> Hmmm, if we are going to add this menu we are discussing then we might need to
> let the user choose between the following:
> 
> 1. Only show installable/Show all

> 2. Show only for current image version (2.9, 3.1, 3.2 etc)

I think you have meant 'Show only for current Squeak version (2.9, 3.1, 3.2
etc)' here.
And this should be the default IMHO, since most packages, which are assumed
to be well separated from the basis image, should work with whatever update
level inside some Squeak version.

Later the coming modules tools should help dealing with this versioning
problems; but however good these tools will be: there always may be hidden
incompatibilities, which are coming to the front in praxis.
This triggers a further idea (I'm thinking loudly): what about an easy to
use feedback possibility, e.g. a feedback button? It could be limited to
'incompatibility' feedback (giving a template to fill out) and possibly
trigger an automatic mail from SqueakMap (after the feedback has reached it)
to the admin of the package then.

Ensuring a high validity of the given compatibility info in SqueakMap for
the packages therein is an important goal to get and beware the trust by its
users. And things may change quickly...

> /Show for all
> versions/Show only for current image version or older

> 
> Now - how do we let the user do these choices? Preferences? (not necessarily
> easy to find) Checkbox items at the top of the menu?

Suggestion:
- filter choices *visible* in title of menu;
- changeable by submenu;
- at first start of the SqueakMap menue at all, perhaps a few explanations
about the default and how to change it in an #inform: message.


Greetings,

Stephan


> 
> regards, Göran
> 
> 
> Göran Hultgren, goran.hultgren at bluefish.se
> GSM: +46 70 3933950, http://www.bluefish.se
> \"Department of Redundancy department.\" -- ThinkGeek
> 
> 


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3