Decentralizing VM development (was Re: [Vm-dev] Re: 64 bit VM, source anyone?)

[Keith Hodges]

> Oh, and I did ask a while back (on the twin of this thread on the
> seaside list) for advice, discussion, doc pointers etc about how to
> handle allowing open access to an MC repo whilst still maintaining an
> official branch etc. No responses; anybody here going to actually help
> rather than whine?
>
> tim
>
Dear Tim,

for seaside and MC in general it appears to have been done fairly
informally. Many people simply load the latest package which includes
the initials of a known-to-be-reliable developer. Installer facilitates
this approach by allowing the initials (or multiple matches including
initials) to be specified in the package name.

Installer ss project: 'Seaside'; install: #('Seaside2.8a1-lr'
'Seaside2.8a1-pmm')

Since the "blessing" scheme implemented in the squeaksource web
interface does not have any in-image mc support. There is nothing to
stop you hijacking the initials field for an informal marker to "bless"
packages. E.g. MyPackage-kph_RELEASE.123 , since MC does give you the
opportunity to change the name of the package before you save it  and
typically it ignores the initials section of the package names.

MC1.5 has better parsing of MC filenames and so enables more
interesting, or should I say more typical, version numbering so that
MyPackage-kph.1.0.12.mcz is a perfectly usable package name. Users can
then pick the latest minor release, and contributions will automatically
be commited as bug-fix releases.

Chris uses another alternative.  He manages Magma in two separate
Repositories, one for developers to contribute to (MagmaTester) and one
for formal releases (Magma).

best regards

Keith