How to defend against changes that break the bootstrap?

[PaulKlint]

We are currently at the brink of switching to a development cycle where we critically depend on previously compiled code (e.g. Kernel, ParserGenerator). This issue is intended to get an overall picture of breaking changes and how to remedy them.

Scenarios that can break the bootstrap

• Changing parameters of commands like rascal, rascalc, rascalTests
  Approach: support transition in Bootstrap script
• Changing name/signature of Kernel functions
  Approach: 1. keep old declaration; 2. add declaration for new version; 3. bootstrap; 4. replace uses of old by new; 5. bootstrap; 6. remove declaration of old version; 7. bootstrap
• Renaming a RascalPrimitive or MuPrimitive
  Approach: 1. keep old declaration; 2. add new declaration for renamed version; 3. bootstrap; 4. replace in the compiler uses of old name by new name ; 5. bootstrap; 6. remove declaration of old name; 7. bootstrap
• Changing the signature of a RascalPrimitive or MuPrimitive
  Approach: 1. Add a test in the body of the primitive whether dealing with the old or the new signature, keep the implementation of the old signature and add the implementation for the new signature; 2. bootstrap; 3; replace in the compiler uses of old signature by new one; 4. bootstrap; 5. remove support for old signature from the body of the primitive; 6. bootstrap.
• Adding field to a serialized Java class, e.g. RVMExecutable
  Approach: add optional FlatBuffer field
• Deleting field from a serialized class
  Approach: make corresponding FlatBuffer field deprecated
• Changing a constructor in the RVM datatype
  Approach: add new version and make old version deprecated
• Switching to automatic compression: |compressed+file:///.../Fac.rvm.ser.gz| to
  |file:///.../Fac.rvm.ser.gz|
  Approach: unclear
• Switching serialization format BinaryReader+FST => FlatBuffers
  Approach: this looks like a huge event; no clear solution
• Moving the compiler sources to another location
  Approach: this looks like a huge event; no clear solution
• Deleting a Rascal language feature (e.g. annotations)
  Approach: 1. remove all uses of the feature from any Rascal code used for bootstrapping
  (e.g. Kernel, ParserGenerator, ...); 2. bootstrap; 3. remove the implementation of feature to be deleted; 4. bootstrap.

Scenarios that cannot break the bootstrap:

• Changing Rascal functions other than Kernel functions
• Changing Java code that is unrelated to serialization
• Adding a Rascal language feature (e.g. coroutines)
  Note: any changes to the existing implementation should be handled according to the above approaches.
• Changing IValue or Type internally, i.e. no API changes
• Adding new IValues or Types