Steph wrote:
- make sure that all the configurations of external libraries arecorrectly defined. In particular we made sure that a version does not depend on a stable one but on a version specific.
I would recommend against using detailed numbered versions for this. That couples you to bug fix patches/updates in the external libraries and creates a very high versioning effort.
In Seaside we use release3 release30 release31 instead of stable. Release3 introduced a different packaging, and 31 has some interface changes. We can now safely promote a new version to stable without having to update all configurations using seaside.
This reduces the versioning effort, at some loss in reproducibility. For that, separate snapshots are perfect.
Cheers, Stephan
I agree with this recommendation ... a very good use of symbolic versions and I plan to propagate this pattern without the gemstone universe...
Dale
On Fri, Jun 27, 2014 at 3:56 PM, Stephan Eggermont stephan@stack.nl wrote:
Steph wrote:
- make sure that all the configurations of external libraries arecorrectly defined. In particular we made sure that a version does not depend on a stable one but on a version specific.
I would recommend against using detailed numbered versions for this. That couples you to bug fix patches/updates in the external libraries and creates a very high versioning effort.
In Seaside we use release3 release30 release31 instead of stable. Release3 introduced a different packaging, and 31 has some interface changes. We can now safely promote a new version to stable without having to update all configurations using seaside.
This reduces the versioning effort, at some loss in reproducibility. For that, separate snapshots are perfect.
Cheers, Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 28/6/14 01:07, Dale Henrichs wrote:
I agree with this recommendation ... a very good use of symbolic versions and I plan to propagate this pattern without the gemstone universe...
Why Java practices would be so wrong? I do not even want to discuss it in fact. With a release version should be fixed. If people do not like it, then I will create and maintain my own configurations. I have no problem with that. In fact it would even simplify our problems.
I'm proposing solutions to avoid to fork but if necessary we will fork. I think that we can fully manage Moose with versionner and this is not the case of Seaside because of platform specific features that are not supported by versionner.
Stef
Dale
On Fri, Jun 27, 2014 at 3:56 PM, Stephan Eggermont <stephan@stack.nl mailto:stephan@stack.nl> wrote:
Steph wrote: > - make sure that all the configurations of external libraries are >correctly defined. > In particular we made sure that a version does not depend on a >stable one but on a version specific. I would recommend against using detailed numbered versions for this. That couples you to bug fix patches/updates in the external libraries and creates a very high versioning effort. In Seaside we use release3 release30 release31 instead of stable. Release3 introduced a different packaging, and 31 has some interface changes. We can now safely promote a new version to stable without having to update all configurations using seaside. This reduces the versioning effort, at some loss in reproducibility. For that, separate snapshots are perfect. Cheers, Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 28/6/14 00:56, Stephan Eggermont wrote:
Steph wrote:
- make sure that all the configurations of external libraries arecorrectly defined. In particular we made sure that a version does not depend on a stable one but on a version specific.
I would recommend against using detailed numbered versions for this. That couples you to bug fix patches/updates in the external libraries and creates a very high versioning effort.
Pressing one button to load one to release and one to commit is not that complex. If necessary we will build a tool that does is automatically. Releasing a real fixed version is important. I'm sorry stefan but we want FULL reproducibility.
We cannot sign contracts when we maintain deployed systems by just saving images and preying.
Stef
In Seaside we use release3 release30 release31 instead of stable. Release3 introduced a different packaging, and 31 has some interface changes. We can now safely promote a new version to stable without having to update all configurations using seaside.
This reduces the versioning effort, at some loss in reproducibility. For that, separate snapshots are perfect.
Cheers, Stephan _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Dale Henrichs -
Stephan Eggermont -
stepharo