Module Versioning and Backward Compatibility Quiz Quiz

Assess your understanding of module versioning best practices and the principles that maintain backward compatibility in software systems. This quiz focuses on key concepts, scenarios, and definitions vital for ensuring reliable updates and integration.

1. Semantic Versioning Components

   Under the semantic versioning convention, which part of the version number indicates a breaking change in backwards compatibility? For example, consider version 2.3.4.

   1. The second number (3)
   2. The third number (4)
   3. The fourth number, if present
   4. The first number (2)

   Explanation: The first number in semantic versioning—known as the major version—signals breaking changes that are not backward compatible. The second number (minor) indicates new features that don't break compatibility, while the third number (patch) covers small fixes. There usually isn't a fourth number in standard semantic versioning, so that option is incorrect.

2. Deprecation and Compatibility

   If a module developer marks a function as deprecated in a new version but doesn't remove it, how does this affect backward compatibility?

   1. The module remains backward compatible
   2. All older code must be rewritten
   3. Backward compatibility is instantly broken
   4. Deprecation forces an upgrade of dependencies

   Explanation: Deprecating a function means it is discouraged for use and may be removed in the future, but currently it still works, which preserves backward compatibility. Removing the function outright would break compatibility (so option 2 is wrong). Older code will still work, so rewriting isn't necessary (option 3), and deprecation doesn't force upgrades automatically (option 4).

3. Version Pinning Scenario

   A project specifies a dependency on version 1.5.* of a module. If the module is updated to version 2.0.0, what is likely to happen during dependency resolution?

   1. The new version will always be installed automatically
   2. The newest patch version only will be installed
   3. Version 2.0.0 will be ignored due to possible breaking changes
   4. An error will occur regardless of compatibility

   Explanation: Most versioning schemes use the first number to represent major changes, often introducing incompatibilities. Specifying 1.5.* only allows patch upgrades within version 1, so 2.0.0 is typically ignored to avoid unexpected breaking changes. The new version will not be automatically installed (option 2), and an error only happens if unmanaged, so option 3 is incorrect. Only patch updates within the specified major version are allowed by the wildcard (making option 4 less correct).

4. Maintaining API Stability

   Which strategy best helps maintain backward compatibility when adding a new parameter to a public function?

   1. Delete all previous references to the function
   2. Replace an existing parameter with the new one
   3. Move the function to a new module
   4. Make the new parameter optional with a safe default value

   Explanation: Adding an optional parameter with a default value ensures that existing code calling the function without the new parameter will still work as before, protecting backward compatibility. Replacing an existing parameter or deleting references would break existing code, and moving the function to a new module does not maintain compatibility by itself.

5. Identifying a Breaking Change

   Which of the following changes is most likely to break backward compatibility in a module's public interface?

   1. Adding detailed comments to code
   2. Increasing test coverage
   3. Updating internal variable names only
   4. Renaming a function that is used by clients

   Explanation: Renaming a public function would break existing clients that rely on the previous name, resulting in a breaking change. Adding comments or improving test coverage does not alter the code's interface and is harmless. Changing internal variable names is safe as long as the public API remains the same.