Hi all!

I don't have the time right now to respond to all - and it would be
better time spent to simply write down my plans - which I am in the
process of doing. Just a few notes:

Using names instead of UUIDs:

Personally I am not that hung up on how we do things but these where my
original reasons:
- The current incarnation of SM is centralized but the plan is to
decentralize it. This means that we will all have a local "server" and
companies/groups may have companywide servers creating at least a three
level deep hierarchy of servers: 1) The master(s) like today 2)
Company/group servers 3) Individual servers
Given this the use of UUIDs for identity makes it much simpler to be
able to create packages "on site" and then be able to publish them when
you so wish. Conflicts in name could then be checked when a package is
attempted to be published "higher up" - and a rename could be done.
Sure, namespaces etc solves this problem but I wanted to try to keep
things simple and evolve them. Making sure that a package has an
identifier that is immutable from birth and also making sure that such
identifiers can be created in a distributed offline fashion without risk
for collision seemed like a very good thing.

- Names can be remembered indeed - that is their advantage. On the other
hand I think people would like to be able to rename their packages. I
just wanted to not base identity on the names because I wanted them to
be mutable. Sometimes you just realize the name was stupid and want to
change it. Sometimes the names use spaces, lowercase/uppercase etc. And
sometimes they are pretty long, like "Win32 Standard VM Configuration
tests" or "Zurgle for Squeak 3.4". 

- I still feel that you can use the name for almost every occasion, such
a reference will work in 98% of the cases. :-) But *inside the model* I
can't see why we should use a scheme that can "fail". Sure, we can make
names immutable but I don't want to do that.

Versions:
-Stephen Pair has already implemented a version number scheme (on SM)
and that is what I am using in SM1.1 for "autoversion". A packagerelease
can also have a version String like today which you can set to whatever
you like. The point with adopting a parallell "autoversion" is that:
	- we will have a standard
	- it is parallell so people can still use their own more descriptive
version names
	- the version scheme has some nice traceability features
	- they are immutable

Dependencies:
- I know how Debian works and I am gladly borrowing ideas from them.
BUT... the dependency model that I am planning is different. Simpler and
IMHO more suitable for our needs. Doing things like have prereqs that
says "version >= 0.9" or stuff like that I personally do not like - how
would you know for sure? And embedding prereqs inside the packages is
IMHO pretty dumb. What if you discover they are wrong? Then you need to
release a new version of the package! And you can only have ONE
dependency description per package. Anyway, I am writing down my plan
for this. I have also discussed the plan with many experienced Squeakers
at OOPSLA and they all liked it.

- The important thing though is that nothing in SM1.1 will implement
dependencies! I am simply adding some simple means for attaching meta
information to Packages and PackageReleases. Using this mechanism we can
then test different models independently from SM. We can also add other
"meta info" if we like.

regards, Göran