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 <[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
