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
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/LockCommandRe... 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
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/LockCommandRe...
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
On 10/30/2015 10:04 AM, Eliot Miranda wrote:
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. Your suggestion implies that Holger would have to "take ownership" of the generated configuration and he would no longer be using the "official" configurations ... If the official configurations for the projects he is using change, how do you propose he merge in those changes?
In git the version that you check out _is already_ a collection of the "fixed specific versions", so there is no need to create and maintain an "automatic configuration generator" .... that's the SCMs job. When using git things get simpler rather than more complex. For example just compare the ConfigurationOfSeaside3[1] (mzc repo) and the BaselineOfSeaside3[2] (git repo). On method count alone there are ~10 times more methods in ConfigurationOfSeaside3 than in BaselineOfSeaside3 ... then look at the methods themselves! [1] http://smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main/Configuratio... [2] https://github.com/SeasideSt/Seaside/tree/master/repository/BaselineOfSeasid...
Why is is about the repository and not the versions? Because versions _should_ be managed by the repository, not the package manager ...
git and other disk based SCMS give me a single SHA (or other identifier) that uniquely identifies the collection of files on disk .. one can tag this SHA and give it a version name ... this is the job of an SCM ... The ConfigurationOf was invented to fill in the gap between what you could do with Monticello and what needed to be done --- which was to tag a _collection_ of packages with a version name --- and manage project and package dependencies .... Metacello does this. But there is more to "to be done" than just tagging a _collection_ of pages with a version name ... One should be able to see the differences between versions: changes to packages plus added and removed packages. Metacello does not do this. One should be able to merge one version into another. Metacello does not do this. Git and other SCM based SCM do show you diffs between versions and you can merge changes between two different versions... as an added bonus you can include your documentation, images and shell scripts in the same directory structure and version them altogether in one swell foop. Rather than attempt to duplicate the entire range of functionality that git and other disk-based SCMs provide, I choose to leverage existing functionality and put my effort into inventing new things in Smalltalk.... Dale
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/LockCommandRe...
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
We released this as Snapshotcello :) http://www.smalltalkhub.com/#!/~girba/Snapshotcello/ http://www.tudorgirba.com/blog/snapshotcello-take-a-snapshot-when-you-re-rea... http://www.tudorgirba.com/blog/snappier-snapshotcello Doru On Mon, Nov 2, 2015 at 12:39 AM, stepharo <stepharo@free.fr> 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 <
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/LockCommandRe...
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"
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-rea... http://www.tudorgirba.com/blog/snappier-snapshotcello
Doru
On Mon, Nov 2, 2015 at 12:39 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> 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 <dale.henrichs@gemtalksystems.com <mailto: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/LockCommandRe...
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"
participants (5)
-
Dale Henrichs -
Eliot Miranda -
Holger Freyther -
stepharo -
Tudor Girba