Package maintenance
ducasse
ducasse at iam.unibe.ch
Thu Oct 9 06:28:21 UTC 2003
Hi all
I just want to share with you the problems with got when we work on KCP
in 3.5 and move to 3.6.
Between 3.5 and 3.6 some packages have been removed and alex did a
changeset Splitter to move the change related to class in different
packages automatically. however the fact that we do not have a complete
representation
of the model of code of Squeak (globals, category rename) then we edn
up doing some stuff manually. Extremely fun to do and sure to lose
changes and introduce bugs. We could easily imagine a system where when
a changes is done, it is split automatically to the package where the
concerned classes are located or to create automatically classes
extensions to the current packages.
So if we are serious about having packages and maintaining when they
are out of the image we should really consider
have package entity (may be package info), support inside the image for
class extension and may be based on something else that monticello
*categories and a complete uniform code fileout that does not contain
doit because wehn you do code analysis you do not want to have to parse
string and to interpret their side effect. So may be this should be the
goal for 3.8.
By the way, I learned that joseph is now developing Ginsu for
VisualWorks, that it is open-source (I imagine that the license
problems are fixed after the discussions between joseph and daniel at
ESUG) and will be distributed in Rosetta format so that people can port
it to the dialect they want. So there would be a good match between
Monticello (performing the
changes/team part), Ginsu offering a metamodel and SM delivering the
packages. I guess that joseph should do a public announce soon.
If this goal would be selected as an important goal for 3.8, I would
***really*** allocate some of my precious time on it
for example to port Ginsu and integrated it in Squeak.
Now we have to decide. Avi would you be interested to have Ginsu as a
core meta-model for monticello?
Stef
More information about the Squeak-dev
mailing list
|