[V3dot9] Re: New PI with postscripts/preamble etc

[stéphane ducasse]

>
> No. :) as the version note (don't you read them?)

I was not using squeak.
So I guess that marcus rolled back because he had problems with the  
underscore fixing.


> says I used the newest
> I found at the 3.9 repo from Marcus (which was not yet in the  
> image) and
> merged that with the newest I found from Squeaksource (from Avi):
>
> "Careful (as best I could) merge (based on md-8 for 3.9 loaded into
> 7054) with the latest avi.20 version from Squeaksource.com/PackageInfo
> which includes preamble/postscript support."
> 	
>>> PPS. There are numerous versions of packages in current 3.9 that  
>>> needs
>>> to get fed "upstream".
>>
>> I do not understand what you mean. That should be loaded in the image
>> or upgraded to
>> SM?
>
> "upstream" typically refers to the "source" of the package, which in
> this case would be the package maintainers.
> Depending on the package the actual "feeding" can be done differently.
> The actual effect we want is for package maintainers to pick up and
> integrate the changes you have made.
>
> If they do not do this - then bad things will happen when the users
> start installing newer versions from upstream sources - your
> fixes/changes will typically get lost and things will break.

Ok I understand.

>>> By that I mean for example SMBase and SMLoader -
>>> my packages. The loader is a fixed version of my latest published -
>>> easy
>>> for me to fold in and make a new release. Same with SMBase. But what
>>> about the others? SUnit for example is way newer than the one
>>> currently
>>> on SM, and the loader lists 3.1.6 as installed (this is all SM  
>>> knows)
>>> but of course in fact the installed version is a derivative from
>>> 3.1.22.
>>
>> What is the loader?
>
> SqueakMap Package Loader. Since SqueakMap maintains its own  
> "memory" of
> what versions of what packages are installed - going directly to the
> source using Monticello for those packages will put the loader in a
> stale state.

;(
But I do not know what to do for that one.

>>> Since it has been installed using Monticello directly SM still
>>> thinks it
>>> is 3.1.6 that is installed. It also offers no new version because  
>>> all
>>> versions on SM lack 3.9 as category - so SM does not think there
>>> are any
>>> newer versions to install (otherwise it would have looked like
>>> (3.1.6->3.1.22).
>>
>> So what can I do?
>
> Well... good question. :)
>
> 1. The problem of the loader showing the "wrong version installed"  
> is of
> course that Monticello does not talk to SM when loading versions -  
> so SM
> sits around with old state. SM could be "smarter" though, I might try
> something there.
>
> 2. For the 3.9 release we can do this:
> 	2.1 Make sure that the packages that are on SM *and* are in the 3.9
> release image are updated in SM. For SUnit as an example this would  
> mean
> registering a new release of SUnit in SM that is categorized for  
> 3.9 and
> that refers to the MC version that is installed in the image. That  
> would
> make the loader show the truth - at least until the user starts  
> loading
> new versions with Monticello again. :)
>
> 	2.2 "Trick" the loader so that it thinks it has installed this  
> version
> from SM. This is done using a doit like this:
> 		SMSqueakMap default noteInstalledPackageNamed: 'SUnit' autoVersion:
> '13'
>
> Note: the autoVersion number can be seen on SM like here:
> http://map.squeak.org/packagebyname/sunit/autoversion/12
>
> Marcus owns SUnit so he can easily do #2.1 above. Then someone  
> needs to
> execute the 2.2 doit in the image.
>
>
> And then of course, there may be other packages that are on SM  
> *and* are
> in the 3.9 release image that needs the above treatment to show the
> truth in the loader.
>
> Any questions? :) :)

Ok I will try to digest....
Did you create a 3.9 category for SM?

Stef