3

The release method I am talking about is this:

  1. Release code that works with both old and new clients (forwards and backwards compatible)
  2. Release client that only works with the new code released in step 1
  3. Release code that removes the backwards compatibility that was supported in step 1

Example:

  1. Add new stored procedure that has modified signature
  2. Add new code that uses new stored procedure
  3. Remove old stored procedure

On a larger scale this could also refer to deprecating versions of internal APIs.

Is there a general name for this chain of releases? If not can we coin a term for this so I can stop calling it "That 3-step release thing that we need to do"

4
  • 2
    I hereby dub this the transient compatibility pattern. Oct 7, 2017 at 0:06
  • 1
    I think that "transition" is a relevant word, though less specific than you want.
    – Kevin Reid
    Oct 7, 2017 at 4:27
  • 1
    @CandiedOrange I used "Transient Compatibilty Pattern" in a conversation yesterday and no one batted an eye. It is now a thing. Feb 1, 2018 at 22:40
  • @TheHonorableSamuelClemens so long as they understood what you meant. Otherwise God help us all. Feb 2, 2018 at 1:10

1 Answer 1

2

Unless there is a deliberate and announce shift to a new API this is called "good practice", "phased implementation", "transitory introduction" or "backwards compatibility" - if the process also introduces a warning when the transitory items are used, (also a good practice), it is called Deprecation.

It is also worth reading up on Semantic Versioning - unfortunately both the practice you are asking about and Semantic Versioning are more common in the open source world than in many commercial organisations.

Not the answer you're looking for? Browse other questions tagged or ask your own question.