You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When modifying code, follow these guidelines for backward compatibility:
7
+
8
+
1. **Remove unused code by default** - If code was added in the current PR and is unused, it should be removed entirely.
9
+
10
+
2. **Only leave "legacy" code when explicitly instructed** - Only maintain backward compatibility for functions, methods, or APIs that are explicitly marked as needed for backward compatibility.
11
+
12
+
3. **Proper deprecation workflow**:
13
+
- Mark deprecated code with clear comments (e.g., `// Deprecated: Use NewMethod instead. Will be removed in v2.0.0.`)
14
+
- Add a `@deprecated` tag in godoc comments
15
+
- For functions/methods: Create a wrapper that calls the new implementation and mark it as deprecated
16
+
- For types/interfaces: Create compatibility layer with clear upgrade path
17
+
18
+
4. **Clean up strategy**:
19
+
- Keep track of deprecated code in a central tracking issue
20
+
- Set timeline for removal (typically 1-2 major versions later)
21
+
- Never silently remove public APIs without deprecation notice
22
+
23
+
5. **Documentation**:
24
+
- Document the deprecated functionality
25
+
- Provide clear migration instructions
26
+
27
+
By following these guidelines, we maintain a balance between API stability for users and keeping the codebase clean and maintainable.
0 commit comments