----- Original Message ----- | From: "Igor Stasenko" <[email protected]> | To: "Pharo Development List" <[email protected]> | Sent: Thursday, June 27, 2013 11:19:03 AM | Subject: Re: [Pharo-dev] Metacello doubt | | On 27 June 2013 15:43, Dale K. Henrichs | <[email protected]> wrote: | > | > ----- Original Message ----- | > | From: "Igor Stasenko" <[email protected]> | > | To: "Pharo Development List" <[email protected]> | > | Sent: Thursday, June 27, 2013 4:26:14 AM | > | Subject: Re: [Pharo-dev] Metacello doubt | > | | > | Just adding some comments: | > | - i avoid using loading bleeding edge | > | because it has problems which only humans can solve: | > | - if there are two different branches, not yet merged it may | > | load | > | not one that you want | > | - even if dependencies is ok, it doesn't means that if you load | > | two | > | latest versions of two packages, | > | they will work | > | | > | so, what i do, is loading a known working config, and then go to | > | monticello and manually picking and loading updated packages. | > | | > | > But once the human has solved the problem, the solution should be | > encoded in a script that can be used by others to solve the same | > problem ... | > | > It's the manual bits that I'm trying to address with the Scripting | > API ... if you know you want to deviate from the standard load | > directives, you should be able to construct a load expression that | > allows you to specify your deviations so you can do your next | > build without requiring manual intervention... | > | | Well, the "bleeding edge" called this way exactly for reasons that it | is unsafe/unpredictable | and hardly formalizeable.
You are putting too much emphasis of the "what" at the expense of "why"... In Metacello #bleedingEdge is a version like any other version. The statement "if you know you want to deviate from the standard load directives" applies to whether you want to "deviate" by loading the #bleedingEdge version of a project or to "deviate" by loading the #stable version of a project, the mechanism in the Scripting API is exactly the same. | I don't see what can be done there: trying to predict a developer's | next move is not something you can do | with software :) The point is not to predict the developers needs ... the point is to allow the developer to express how he wants to deviate, without forcing him into manual operations... and this is something you can do in software:) | As i said, if there at least two persons working on project , each in | his own branch, a term "bleeding edge" will mean | something different for each of them. Only when one person takes an | effort to merge and update config, you'll have new development | version, but before that, if they will commit often without merging, | the bleeding edge will jump between one branch and another, and i do | not see how that can be useful to anyone. Your comments are specific to the #bleedingEdge version ... as I said earlier, the mechanism that I have described does not apply to only the #bleedingEdge case, but to all versions ... When I said that I would "add test cases for the #bleedingEdge use case," I was actually thinking that I wasn't sure that symbolic versions would work as _I_ expected, since I don't recall adding any tests involving _symbolic versions ... I generally don't want to add features to Metacello that are specifically tied to support a narrow range of use cases, unless I can generalize the feature to cover a wide range. I also don't want to forbid certain use cases just because I don't think they are useful. The Scripting API was invented to give developers explicit control over what gets loaded by Metacello, because the vanilla load of a project and it's dependents is not always what a developers needs ... Dale
