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 <nicolaihess@web.de> 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?