We are doing a #cleanUpForRelease when loading the update…
We could maybe
-> just call “Smalltalk #cleanUp” on update (preserves the change sets)
-> do the full cleanup *only* on the CI server
Yes, that sounds better. I will add an issue for that.
The reason why I want to do a release clean is that the idea of the CI server
is that
we build *the artefact of release*, with not even the tiniest human
intervention needed.
In the past we finished, and then, completely burned out, called
#cleanUpForRelease in the
manual build of the download, —> everything broken. If we would have build the
complete
release automatically, that would never have happened.
There is another proof: Of course what we do not do is anything related to
.sources and .changes,
and even condensing the changes file is broken…
Marcus
On 15 Jan 2014, at 22:26, Nicolai Hess <[email protected]> wrote:
> This is what happens duing an update (30697 - 30698)
>
> save old cs Unnamed
> new changes 30698-Pha-Update
> new changes ScriptLoader30-MarcusDenker.853
> new changes 30698-Pha-Update
> new changes Metacello-MC-MarcusDenker.696
> new changes 30698-Pha-Update
> ChangeSet cleanup
> new changes Unnamed
> restore old cs <no name -- garbage?>
> new changes <no name -- garbage?>
>
> the old changeset is saved
> update stream starts->
> every package update creates a new changeset
> scriptloader calls cleanup
> update stream ends
> old (cleanuped) cs is restored
>
>
> now every change goes to this unnamed changeset.
> If you open the changesorter it calls "ChangeSet current"
> which creates a new unnamed ("Unnamed") changeset and
> of course the prior changes are lost.
>
>
> Is this inevitable?
