We released this as Snapshotcello :) http://www.smalltalkhub.com/#!/~girba/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]> 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]> 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 "Every thing has its own flow"
