On 03/05/2018 09:07 AM, Guillermo Polito wrote:
On the other side, there is the fact that Metacello baselines are so
far nice to describe release project dependencies, but they are not so
nice to describe subprojects/development dependencies that may get
edited along with the parent project. Kind of what we used to do with
#bleedingEdge. I feel this is a complex problem, that not even SBT or
maven that are there since years are capable of solving nicely... Tode
and Iceberg metacello integration try to solve this problem by
"ignoring the dependency and using the loaded repository" but this may
not be successful either...
I have not been following this thread in detail, but this comment leads
me to believe that the issue that you guys are running into has to do
with trying to ongoing distributed development across multiple projects
and multiple platform versions ...
If so then I think that the moral equivalent of #bleedingEdge should be
a branch structure along the lines of:
master branch --- the project release that is known to work on all
supported platform versions.
dev_pharo6 --- the current #bleedingEdge for Pharo6.0
dev_pharo7 --- the current #bleedingEdge for Pharo7.0
In an image where you want to use the dev_pharo7 for a project, you do a
Metacello lock on github://xxxx/xxx:dev_pharo7/src BEFORE loading the
project ... if there are multiple projects that need to all coordinate
development then you follow the same convention and use a Metacello lock
for each of the projects ... Executing expressions to lock projects is
tedious to use and manage.
In tODE I started using project entries[1] that are downloaded to disk
and shared by multiple images that allow a developer to specify what
branch/tag/commit they are interested in using ... each image that is
started up in a "cluster" uses the project entry to do a Metacello lock
on the project "automagically"... if there is a series of projects where
the developer needs to use dev_pharo6 they can arrange to edit the
project entry to reflect the proper branches for the set of projects
that need special _development_ treatment ... these .ston files can be
shared amongst groups of developers ... of course once the local clones
of these projects are on the local disk, then it is up to the developer
(or a set of scripts) to periodically update to the latest development
version of each of the projects ...
To share a specific configuration of development git repos, you need to
know that SHA anyway, so the image can produce a collection of project
entries with the SHA of the commit and those project entries can be
included in a bug report ...
For Rowan[2], I am using a "load specification"[3], which is a second
generation project entry .... the Rowan work is still evolving ...
Anyway, I think that putting the control of what is being used for
development completely in the developers hands and avoiding the need to
edit baselines is a good thing ... and I think that the idea of having
specifications that are shared by a cluster of images is a good way to
go ...
Dale
[1] https://github.com/GsDevKit/GsDevKit_home/blob/gh-pages/Seaside32.ston
[2] https://github.com/dalehenrich/Rowan
[3] https://github.com/dalehenrich/Rowan/blob/master/specs/Rowan.ston
