You can do that using the expression:
PharoChangesCondenser condense
Although that also means you lose the version history of methods
inside your image. This is typically not done a lot, maybe for
production deploy, maybe for release of Pharo itself.
Yes, but we need to change that. The artefact on the CI server needs
to be the artefact of release. We should not have *anything* of the
kind “and a day before release we call X”.
Because for sure it will be broken. And we waste resources: the
changes are the history of the revision control system.
OK so a silly and not-so-innocent question: Why not include that in
the build script *right now* ? It has to be done some time, and now
the discussion is open why not make use of the opportunity?
Also, my use of the changes file is uniquely to recover in case of a
crash. With condensed changes for every daily build I download this
would make my recovery just that bit easier. One small change …
From a size point of view it would make sense: a “Pharo4.sources” is
even a bit smaller than the current .changes (which itself would be
empty). Compressed it would be 15,7 instead of 13,7 due to the .changes
being better compressible (it contains much useless things even by
that metric…)
The problem is that we would need to see how it plays with the
get.pharo.org <http://get.pharo.org> where the vm download contains
all of Pharo1, Pharo2 and Pharo3 sources…
I do not understand your stress. If we produce a condense change files
what is the problem.
You are talking about the problem of having multiple .sources?
This is a real mess… I am locking forward to a time when we just have
one .pharo image.
Marcus
