Yes now I remember :)
Stef
Le 1/11/15 15:51, Tudor Girba a écrit :
We released this as Snapshotcello :)
http://www.smalltalkhub.com/#!/~girba/Snapshotcello/
<http://www.smalltalkhub.com/#%21/%7Egirba/Snapshotcello/>
http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-ready
http://www.tudorgirba.com/blog/snappier-snapshotcello
Doru
On Mon, Nov 2, 2015 at 12:39 AM, stepharo <[email protected]
<mailto:[email protected]>> wrote:
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]
<mailto:[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
--
www.tudorgirba.com <http://www.tudorgirba.com>
"Every thing has its own flow"
