[SERVER-64089] Ignore checking fields in IGNORE_UNSTABLE_LIST in IDL compatibility checker Created: 01/Mar/22  Updated: 29/Oct/23  Resolved: 23/Jun/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Bug Priority: Major - P3
Reporter: Huayu Ouyang Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2022-05-16, Repl 2022-05-30, Repl 2022-06-13, Repl 2022-06-27
Participants:

 Description   

Currently, we skip certain compatibility checks if the field is unstable. We skip the checks by only checking if the old version of the field is unstable. This is normally correct because we don't allow changing the field from stable in the old version to unstable in the new version. However, we now have some special cases in IGNORE_UNSTABLE_LIST where the field has changed from stable to unstable. We should change the script so that wherever we skip the compatibility checks if the old field is unstable, we also skip it if the field is in IGNORE_UNSTABLE_LIST



 Comments   
Comment by Githook User [ 23/Jun/22 ]

Author:

{'name': 'Vesselina Ratcheva', 'email': 'vesselina.ratcheva@10gen.com', 'username': 'vessy-mongodb'}

Message: SERVER-64089 Ignore checking fields in IGNORE_UNSTABLE_LIST in IDL compatibility checker
Branch: master
https://github.com/mongodb/mongo/commit/835f85779c753dfefea25e92bc9224b4642a6d06

Comment by Huayu Ouyang [ 28/Mar/22 ]

I checked and there isn't be a difference between 2) and 3). If a field has been previously ignored as unstable, and we change it back to stable, that change to stable is just as hard or easy as 2), which currently is just changing the field from unstable: true to unstable::false. I filed SERVER-65004 to make this harder for users to do.

Comment by Judah Schvimer [ 28/Mar/22 ]

I think we want to ensure that:

  1. stable fields generally cannot become unstable (unless we made a mistake on an internal field that we never documented as stable and feel comfortable fixing that mistake)
  2. it's hard to make an unstable field stable: essentially, this should be an explicit choice and not something that's easy to do accidentally or by mistake
  3. if a field has previously been ignored as unstable and then we change it to stable, that change to stable should still be "hard and explicit" per the above, so that we ensure it's a very explicit choice where we know the stability requirements we're opting into.
Generated at Thu Feb 08 05:59:29 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.