Markus Gaelli <gaelli at emergent.de> wrote:
> Hi folks,
> 
> after having used envy for six years and Store for one I also feel 
> obliged ;-)
> to make a suggestion.

Indeed. In fact - I want people to understand that I am no expert
regarding the above mentioned systems.
I have used Envy a couple of years ago and even though it was nice in
some regards, it was also "mysterious".

I also know CVS pretty good.

And I have thought about the problem and have a plan. But I still want
to hear thoughts and questions! :-)

> I would like to have a model with packages and package versions. That 
> is it.

Ok, we have that. :)

> I think the difference to the package / configuration proposal is, that 
> in my
> suggestion the code can be stored in package versions,
> which _can_ refer to other versioned entities.

Yes.

> But also one can try to load the newest possible configuration of a 
> package.
> This just tries to load all the newest versions of it and of all its 
> prerequisites.

Eh, I can't see why we/I can't do the same using my proposed model.
I don't think I understand.

> If that works, fine, you can just store that as a new version.

Store "what"? A map or something?

In my model you would instead do either:
- Store new package configurations for selected package releases.
- Store a load script consisting simply of the package releases you know
have loaded.

> Here again that boring SmaCC-Development example to illustrate
> some possible usage:
> 
> Package(SmaCC-Development) >> versions
> 	-> #(
> 		PackageVersion(SmaCC-Development 1.2)
> 		PackageVersion(SmaCC-Development 1.1))
> 
> PackageVersion(SmaCC-Development 1.2) >> prerequisiteVersions
> 	-> #(
> 		PackageVersion(SmaCC-Runtime 1.1)
> 		PackageVersion(RB 1.7623) ...)
> 
> Package(SmaCC-Development) >> untestedLatestPrerequisiteVersions
> 	-> #(
> 		PackageVersion(SmaCC-Runtime 1.1)
> 		PackageVersion(RB 2.0) ...)
> 
> Note that you could try to automatically load the newest/best(?) 
> versions of
> a Package based on this (computed) untestedLatestPrerequisiteVersions
> (RB 2.0 instead of RB 1.7623):
> 
> Package(SmaCC-Development) >> loadWithUntestedLatestPrerequisites
> 	-> loads #(
> 		PackageVersion(SmaCC-Development 1.2)
> 		PackageVersion(SmaCC-Runtime 1.1)
> 		PackageVersion(RB 2.0))

This sounds like my "package configurations" but you have limited then
to only two.
Note that since "package configs" in SM2+ will be SMResources and they
are categorizable just like packages, package releases and even accounts
are today. This means we can categories package configs as "Seems to
work" or "Has been deployed" etc.

> This should store its currently loaded versions somewhere, if you have 
> tested it
> enough you just commit it and a new PackageVersion(SmaCC-Development 
> 1.3)
> is automatically created and send to SM.

This sounds very much like what I want people to do with package
configurations.
It should be a very simply procedure (press a button) to submit a config
that works for someone.

> A PackageVersion can include code but does not have to do so,
> as its prerequisiteVersions can.
> Have I overlooked much? Is this far away from Gorans ideas?

I think it is close - with the exception that you have limited the
numbers of configs to two, and that you still want them to be a part of
the package release. Note that in my plan they are more like
"attachments" to the package release - so attaching one does not force
the package release to be released again. This is IMHO important. The
package release should IMHO - and isn't that actually obvious? :-) -
ONLY be released anew if the CODE of the package has changed. Isn't that
what a release MEANS? :-) Making releases that are exactly like the
previous ones seems so very wrong to me.

> I just saw that he also wrote a mail right now, also using some
> illustrative examples... :-) Have to read this now...
> 
> Regards,
> 
> Markus

regards, Göran