Hi Dale,
but why can't Metacello provide something really simple that automatically
generates a configuration with all the prerequisites fully defined as fixed
specific versions? Then Holger can easily freeze his release using the new
confit and continue his internal development using his current configuration.
Why is is about the repository and not the versions? Seems like the tail
wagging the dog to me.
_,,,^..^,,,_ (phone)
> On Oct 30, 2015, at 12:44 PM, Dale Henrichs
> <[email protected]> wrote:
>
> Holger ...
>
> Frankly this is one of the main reasons I have headed down the path of using
> "git" (or any other disk-based scm) for GsDevKit/GLASS ....
>
> If all of the applications that you use are managed under "git", then for
> production you make local clones for all of the projects including your own
> ... Use the Metacallo lock[1] command and lock each project to reference your
> local filtree/clone ... then when you use "Metacello new" to load projects,
> the "locked" versions have precedence and there is no need to modify all of
> the configurations/baselines or try the half a dozen other hacks ...
>
> With the approach you can have a development set of project clones, a sandbox
> set and a production set ... and all three subsystesm use the exact same load
> scripts ... you simply change which repositories are locked ...
>
> Managing locks can be tricky, but it's a problem that I've solved with tODE
> as well, use .ston files that contain a "project entry" specification object
> with a number of fields including whther or not the spec is locked... when an
> image (stone in the case of GemStone) comes up it looks for "project
> entries" on disk and it then registers those projects in the Metacello
> Project registry ... voila _if_ you load one of those locked projects your
> local clone will be used ...
>
> I will talking about these things at the upcoming Smalltalks in Buenos Aires
> ...
>
> Dale
>
> [1]
> https://github.com/dalehenrich/metacello-work/blob/master/docs/LockCommandReference.md
>
>> On 10/30/2015 03:10 AM, Holger Freyther wrote:
>> Hi,
>>
>> I have an application that is about to be moved into production. Currently
>> it is
>> pulling "stable" or sometimes bleedingEdge of other configurations. After the
>> system moves from testing into production I would like to have tight control
>> of
>> which packages are updated from one version to another. E.g. not have a
>> Voyage "stable" upgrade just because there is a new stable version but
>> probably
>> at the same time still use a symbolic reference myapp-stable-5 to load the
>> package?
>>
>> Is there a common/known to work approach. I could identify all used Metacello
>> configs and move them to my own infrastructure and then copy the use packages
>> as well. Is there tooling support for adding such a "freeze"? How do other
>> handle
>> a release of an application that needs to be updated in an "incremental" way?
>>
>> cheers
>> holger
>
>
