I implemented something like that for Moose.
It walked all the configuration and generate a <frozen> method with all the versions packages
So I did not have to ask people to version their versions.
I can dig it up if you want (it is draft).
Stef
Le 30/10/15 10:04, Eliot Miranda a ��crit :
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 <dale.henrichs@gemtalksystems.com> 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