Am 30.11.2004 um 20:29 schrieb goran.krampe@bluefish.se:

Hi!

=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:

...

Hi goran

We would like to be able to manage the code of some packages with squeakMap but without having to create one package for each version (look at RB for example). Have you plans to have that?

You mean one for each *Squeak* version? Well, I am not familiar with RB in this case - is it different for 3.7, 3.8 and 3.9? I mean, how does the RB "version tree" look?

It forked after "for 3.6". As the RB-Nodes are in 3.9, but not in 3.7. And the 3.8 has the Browser registration, which is not in 3.7. Thus there are 3 versions, each of them is updated regularly. (3.7 updates will stop as soon as 3.8 image is final)

You know - the current SMPackage has an OrderedCollection of SMPackageReleases and each release knows its ancestor simply by their place in the collection. I intend to add a previousRelease instvar so that they can form a tree with branches.

Even though, I think you can have one RB package today too. Though crude, the SMLoader will try to find the newest published release for your Squeak version.

I tried that a couple of weeks ago, did not work: SMLoader installed a version tagged to be for 3.8 in 3.7m but I will try again. But this seems to be not that simple to maintain, even if it works.

Marcus

Goran

I think that SM is cool and REALLLLLLLLY IMPORTANT for all of us and it is a success for the end-user so please please keep your energy for that! (I mean focus and release a new version the user interface also to publish package is not really sexy for new comers, the replication could be better).

We need a good dependency/configmap mechanism. I'm not good there so I will never ever think that I can do something in that area. You had a vision and you know what you want so please do it.

What I want to say is that I appreciate your ideas for languages but I appreciate much much more your tool since everybody in squeak is using them, so please do not get trap in the language featuristic. We need SM2 we need a good package mechanisms and all the rest is much much minor compared to that.

And believe us we will do it so that we get the best that we know. But for SM you are the expert and we are waiting for SM2 :)))) YES really.

Stef

Marcus Denker denker@iam.unibe.ch wrote: [SNIP]

...

...

Even though, I think you can have one RB package today too. Though crude, the SMLoader will try to find the newest published release for your Squeak version.

I tried that a couple of weeks ago, did not work: SMLoader installed a version tagged to be for 3.8 in 3.7m but I will try again. But this seems to be not that simple to maintain, even if it works.

True, it is ugly (and you may be right that it doesn't work properly), I simply need to get my butt in gear and get the next SM out with support for these branches - right? :)

...

Marcus

regards, Göran

Am 30.11.2004 um 22:02 schrieb Boris Gaertner:

"stéphane ducasse" ducasse@iam.unibe.ch wrote:

...

We would like to be able to manage the code of some packages with squeakMap but without having to create one package for each version

With the release of Squeak 3.7 this became a real necessity. My strategy for more or less version-independent packages is to create sar-files. In the preamble I write statements like:

self fileInMember: 'basicCode.cs'. SystemVersion current majorMinorVersion < 'Squeak3.7' ifTrue: [self fileInMember: 'stuffFor36.cs'].

stuffFor36.cs contains selected updates, but, most important, it contains class methods for the old initialization pattern.

Is this a solution for you?

not really, as we would like to just ship .mcz files from Squeaksource.

Marcus