9 May
2015
9 May
'15
11:15 p.m.
Hi Stef,
On Sat, May 9, 2015 at 2:58 PM, stepharo <stepharo(a)free.fr> wrote:
Hi,
What I hope to do is to be able to release Moose with versions and that
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. 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"