I'd like to reiterate that the purpose of the recent MC upgrades is to
wean ourselves off of the unsustainable nature of file-based
repositories; that they only expose an API that does not require them
to enumerate ALL version names.

The changes are also designed to accomodate the limitation of
FileBased repositories that they cannot quickly access their objects
(e.g., the Versions), just their names.

In light of this, a first-class MCVersionName is a logical and valid
part of the MC domain.

>> When I wrote prefix matching, I really meant it. It's a feature of Installer. The following used to work:
>>
>> Installer squeaksource
>>       project: 'OCompletion';
>>       install: 'Ocomple';
>>       install: 'Ocompletion';
>>       install: 'Ocompletion-';
>>       install: 'Ocompletion-u';
>>       install: 'Ocompletion-ul';
>>       install: 'Ocompletion-ul.';
>>       install: 'Ocompletion-ul.8';
>>       install: 'Ocompletion-ul.86';
>>       install: 'Ocompletion-ul.86.'
>>
>> Here's a real script from the Xtreams repository (www.squeaksource.com/Xtreams.html ) using this feature:
>>
>> Installer squeaksource
>>       project: 'Xtreams';
>>       install: 'Xtreams-Support';
>>       install: 'Xtreams-Core-';
>>       install: 'Xtreams-Terminals-';
>>       install: 'Xtreams-Transforms-';
>>       install: 'Xtreams-Substreams-';
>>       install: 'Xtreams-Parsing-';
>>       " --- tests follow --- "
>>       install: 'Xtreams-CoreTests';
>>       install: 'Xtreams-TerminalsTests';
>>       install: 'Xtreams-TransformsTests';
>>       install: 'Xtreams-SubstreamsTests';
>>       install: 'Xtreams-ParsingTests';
>>       " --- following require FFI --- "
>>       install: 'Xtreams-Xtras-';
>>       install: 'Xtreams-XtrasTests'.
>>
>> Actually the dash at the end of the package names is mandatory because of prefix matching. Without those Installer used to install the tests if those have higher version numbers.
>>
>> I consider removing the prefix matching a good idea, but we should care about backwards compatibility too.

Ok, I did not realize that such intense prefix-matching was being
used.  Is it really satisfying an essential use-case or just a
convenience?

If the former, we could replace the required API of MCRepository;
#versionNamesForPackageNamed: with #versionNamesBeginningWith:  ??

> E.g., Monticello was designed to not care about version names at all. It just looks at the file name extension to decide which reader class to use. Apart from that, the filename can be anything. That's why the version name field when saving a package snapshot is freely editable. It doesn't even have to match the package name, because the package name is part of the meta data stored inside the mcz. And to identify the exact version, its GUID is used.

Well, what good use is there of trashing all structure of
version-names?  How many people name versions of their package
inconsistently like that and what is the benefit?  In my view, that
creates confusion and disharmony.

We need a mechanism that supports unified MCRepositories that
accomodate the aforementioned weaknesses of the FileBased while still
maintaining some chance of sustainability.

> The only place in MC making assumptions about the meaning of filenames used to be in its UI.

I believe the meaning of "filenames" (we should call them "version
names") is now essential, that's true.  I actually see this as a good
change.  What you didn't mention is that MC no longer has places
assuming FileBased repositories except in its FileBased repository
inspector.

> The recently introduced MCVersionName tries to push these conventions into MC itself, which IMHO is not a good idea. It is reasonable to put all the file name parsing in one place. But making it part of the MC data model is wrong. It could be part of the UI, or a utility, but putting it in 'Monticello-Modeling' gives it way too much weight.

Well, I simply disagree.  I think its crucial that we nail-down MC
version names with some structure so we can move forward with
improving the tools.

Regards,
  Chris

PS - One of the things these MC changes have done is facilitate a
Magma-based MC repository in which every MCDefinition is
canonicalized.  I added two menu entries to the methods-list in the
browsers:  'mc versions' and 'mc origin', which instantly show all
versions of that method from the MC repository and the earliest
occurence of that method, respectively.