Hi Stef,

On Sat, May 9, 2015 at 2:58 PM, stepharo <stepharo@free.fr> wrote:

Hi,

Yes, I think we have a different point of view on what Moose is.

I do not expect people to fork, but if they do, I would expect them to do it in a public place and help us maintain the configuration(s). For example, we could have:
- a Moose/Moose51 repository
- commit packages with new patches for Moose 5.1 only there, and
- modify the #stable version corresponding configurations to load those new packages.

This is doable. Would that be Ok?

Cheers,
Doru

I do not know because I do not really understand your solution.

What I hope to do is to be able to release Moose with versions and that Moose could be released every month.

I would have no problem releasing Moose every month. In fact, I argue that we should release it every day when the build is green.

Except that Moose 5.0 was released on Pharo 3 in December, and since then (5 months) nobody issued a request of change on that release. It either means that people are happy with that version, or that they are Ok with using the latest Moose which happened to be developed on top of the development version of Pharo.

To ensure that the process that stresses the latest version works, I use the latest Moose in production every day (even for tools that are used by others).

But, if someone is using an older Moose and they need a patch, we can create a repository for these patches (e.g., Moose/Moose51), and we just modify the stable version of the configuration to load the patched packages from this repository. This would give people a simple way to provide these patches, and we would keep Moose/Moose for the head development.

We will see that with christophe ppm.

I am certainly looking forward to it.

Now not having versions (or may be there are released moose versions based on exact version number) and
a nearly systematic way to work on alpha of Pharo is clearly the best way to have most of the risk when you need stability.
(And I do not talk about people having to change all the roassal code in the middle like olivier for his paper on artefact).

Moose 5.0 is a version. And Moose 5.1 will be another version.

And you should understand that people from RMOD are not complaining to me. I think that some of them just do not use
recent versions of Moose take one and stay with it.

That is an option that people can choose. It's not ideal for the rest of us, but I am happy it works for them.

Now I'm curious to know if we can rebuild an old Moose image.
So this means that people should not use an image automatically built (I sincerly hope that I'm wrong here).

Yes, you are basically wrong. Up to Moose 4.9, we had a snapshot and hardcoded versions. This proved to be not maintainable in the longer term. For example, when someone needed to fix something in one of the deeply nested projects (like Rubric), it was not clear which versions should be updated.

So, starting with Moose 5.0, we moved to only having #stable of moose to depend on other #stable of all other configurations. This is much cheaper to maintain. However, it also implies a small variability. We could still do a snapshot together with the #stable version, but in practice it proved to not be needed.

The Moose 5.0 job ensures exactly that:

https://ci.inria.fr/moose/job/moose-5.0/

I did not talk recently to synectiquers but they do probably the same and I understand them.

What should they do?

Cheers,

Doru

Stef

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

www.tudorgirba.com

"Every thing has its own flow"