Deprecate v0 API in favor of v1/v2 APIs

[jennijuju]

The Lotus v1 API has served as the primary interface for internal usage and applications/services integrating with Lotus nodes for over a year. In addition, with F3 launched in the network, we have also started to work on v2 APIs to add F3-finality awareness APIs. That said, we should officially mark v1 API as stable, v2 API as experimental, and v0 API as ready to be deprecated.

Current API Status

• v0 API: Stable (but to be deprecated)
• v1 API: In production for 1+ year, to be marked Stable
• v2 API: Experimental (F3-aware)

Motivation

1. Technical Debt: Maintaining multiple API versions increases maintenance burden and complexity
2. Feature Parity: New features are often added to newer API versions first, creating inconsistencies
3. F3 Integration: v2 APIs are designed with Fast Finality (F3) in mind, which will become increasingly important
4. Ecosystem adoption: Encouraging ecosystem migration to newer APIs enables better feature adoption

Proposed Deprecation Timeline

Given that v1 API has already been in production use by major users for over a year, an accelerated deprecation timeline could be considered here. (Though we should have worked on upgrading v1 API to stable sooner)

Phase 0: Feature Freeze

• Stop adding new features to v0 API (which we have already been doing for over a year)
• Mark v1 API as stable
• All new features only available in v1/v2 APIs
• Increase visibility of deprecation warnings

Phase 1: Announcement (2 months)

• Create deprecation notice in documentation
• Add deprecation warnings to v0 API responses (via headers or logs)
• Publish migration guide from v0 to v1/v2
• Announce in release notes and community channels

Phase 2: Deprecation (2 months after announcement)

• Mark v0 API as deprecated in code
• Add runtime warnings for v0 API usage
• Provide tooling for API migration verification

Phase 3: Removal (3 months after announcement)

• Remove v0 API endpoints in a major version release