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> 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
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