As a workaround, you can manually edit the changesets.

On Monday, February 17, 2003, at 09:03 PM, Richard A. O'Keefe wrote:

>  I spent much of last night coding up and testing #collect:into:.
>  (Why so much time?  Because of the need to check all versions of
>  #collect: in the system to make sure I wouldn't break anything.)
> 
>  On the way, I found a number of interesting things.
>  For example, Path>>collect: and Path>>select:
>  were totally broken in Squeak 3.0 and 3.2.  I have to assume that
>  nobody ever used them.  The change set I am developing fixes them.
> 
>  One of the nasty things when you are replacing parts of the core
>  is that you have to be *very* careful about the order you do things.
>  I discovered this the hard way, meeting the emergency evaluator for
>  the first time (and the second and the third and ... sigh).
> 
>  We have
>     Collection                >>collect:
>       SequenceableCollection  >>collect:
>         OrderedCollection     >>collect:
>           SortedCollection    >>collect:
>  and you have to
>  (1) plug in the rest of the collect:into: framework,
>  (2) replace Collection>>collect:
>  (3) remove SequenceableCollection>>collect:
>  (4) remove OrderedCollection>>collect:
>  (5) remove SortedCollection>>collect:
> 
>  If you do step (4) before doing step (3), it's emergency evaluator 
>  time.
> 
>  Once I realised what I was doing wrong, I started up a fresh system,
>  loaded the new methods, and then did (2..5) in the right order.  
>  Hooray!
>  It all worked.
> 
>  So I saved the lot as a change set, started up a fresh system,
>  loaded the change set, and HELLO EMERGENCY EVALUATOR!
> 
>  Reason: the change set did not save the removal steps in the order I 
>  did
>  them, but in ALPHABETIC order!  That moved step (4) before step (3) and
>  disaster predictably struck.
> 
>  Q1:  Why are change sets saved in alphabetic order rather than
>       chronological order?  It seems obvious that this is likely to
>       break change sequences.
> 
>  Q2:  Is there any way I can tell change management to use chronological
>       order instead?
> 
>  Q3:  At the moment, I'm dealing with the problem by manually shuffling
>       the removal directives whenever I save a new version of the change
>       set.  Is there a better way to do this?
> 
>  Q4:  I'd like the change set to be usable in 3.0, 3.2, and 3.4.
>       Is it OK if a change set file contains directives to remove 
>  methods
>       that don't exist?  How do I make one remove a method from a 
>  _class_
>       that might not exist in some version?
> 
>