Yet Another Dependency Proposal: Packages and PackageVersions, that is it

Markus Gaelli gaelli at emergent.de
Wed Nov 19 13:19:26 UTC 2003


Hi Göran,

> I meant the (1) "prerequisiteVersions" and (2)
> "untestedLatestPrerequisiteVersions" but now I see you wrote "computed"
> about the last one. I assume you compute that list by taking the latest
> release, looking in there - and then picking the latest release of each
> of the package releases listed.
Right.
>
> Can't really see the big "point" with that part. I mean, the dependency
> resolution engine can calculate such proposals on the fly.
Not a big point, only wanted to say, that it is easy and possible with 
my
approach too.
>
>> 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.
>
> And what if I discover it works with other releases too? Can I then 
> make
> yet another release of Torstens package? And is that a fork?
See below.
> And what
> happens to all other package releases that depends on Torstens release,
> they suddenly points to an old release -
- and are sure to work as they did before -
>  thus you get "cascading
> changes" which will simply create a big soup of releases that are only
> meant to "adjust" the dependency information.
I thought we agreed on the fact, that both our solutions are facing 
that problem,
but also both solutions can version everything by pressing a button 
(after having
tested it).

The version just should say somewhere that it is (not) meant to be the 
mainline
of the evolution of this package. The power to tag some version as 
mainline or
"newest best version of this package since the invention of slided 
bread"
could be authorized to package-maintainers /co-maintainers only.

And I believe that the level of trust/security which just was 
introduced with
Squeakpeople would work fine for many cases. I for example would be
happy to give the right to release a new mainline version of
SmaCC-Development to any journeyer or master.
The one thing which sucked most in Envy was the user authorization.
In almost any project we ended up to use a default user for everybody...

If someone would needed the developer-package with some older or 
unstable
versions of some prerequisites, he or she definitely should be able to 
do so.
And yes, version the whole package. And this should be allowed also to 
apprentices.
The version just should be tagged as not being mainline.
> I also want others to be able to help me adjust that knowledge, but I
> don't want others to be able to do releases (unless I have given
> co-maintainership of course).

(See above)

Regards,

Markus



More information about the Squeak-dev mailing list