Hi Gö(!)ran,

(finally I got that right ;-)

>
>> 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.
I only wanted to say that my model should able to that too, sorry for 
being
not to the point here.
>
>> If that works, fine, you can just store that as a new version.
>
> Store "what"? A map or something?
No maps. Just a new PackageVersion. See example below.
>
> 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.
Which two? Now I don't understand. Maybe I should have said explicitly 
that
PackageVersions can act as "ConfigMaps", so we wouldn't need ConfigMaps.

Say if Torsten Bergmann is creating a Developer-Package, he just says on
which versions of RB, LookEnhancements... this would work. And versions 
this
"Developer-Package". No need for configmaps.
>
>> 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,
again, unclear to me...
>  and that you still want them to be a part of
> the package release.
Indeed.
> 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 think of releases as of breedable eggs.
So I can release an egg, either because I laid a new kind of
egg in the pine or because I found out that a certain egg is also
breedable in oaks and not only on pines. For me it seems CLEAR :-)
that the environment of the egg is as important as the egg itself.

Gack, gack and best regards,

Markus