28 Jun
2014
28 Jun
'14
12:56 a.m.
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
28 Jun
28 Jun
1:07 a.m.
New subject: Point one
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(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:16 a.m.
New subject: Point one
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(a)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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:13 a.m.
New subject: Point one
On 28/6/14 00:56, Stephan Eggermont wrote:
Steph wrote:
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
- 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3842
days inactive
3843
days old
3 comments
3 participants
participants (3)
-
Dale Henrichs -
Stephan Eggermont -
stepharo