On Mon, Mar 5, 2018 at 8:07 PM, Dale Henrichs <[email protected]> wrote: > > > 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
for Pharo master is the current released version and dev the bleeding edge > > 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. Do you have a text explaining what is a lock? I do not understand the problems locks solve. > > 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 >
