Path to 1.0

[trungda]

Hi, just curious what would it take to go to 1.0 for this project? Mainly I am wondering what are the potential breaking changes that might happen before we reach 1.0. Thank you for the great project!

[github-actions[bot]]

👋 Thanks for opening this issue!

Get help or engage by:

• /help : to print help messages.
• /assignme : to assign this issue to you.

[drmingdrmer]

Thanks for your interest in the project!

Most changes from 0.9.0 to 0.10.0 have been minor API adjustments without functionality changes. Looking ahead to 1.0, I expect similar patterns - primarily internal refactoring and improvements that rarely affect the public API.

When breaking changes do occur, they're typically straightforward upgrades. For example:

Type parameter generalization: RaftDataMetrics<NID> --> RaftDataMetrics<C>

Iterator to Stream conversion:

// Before
for (entry, responder) in entries {}
// After
while let Some((entry, responder)) = entries.try_next().await? {}

Error type refinement:

// Before
async fn read_vote(&mut self) -> Result<Option<Vote>, StorageError<C>>
// After
async fn read_vote(&mut self) -> Result<Option<Vote>, io::Error>

We minimize breaking changes even during major functionality upgrades. When possible, we provide compatibility layers. For instance, an upcoming network API change from request-response to stream-oriented will include default implementations that delegate to existing user code, avoiding breaking changes.

Upgrade support:

• All examples are maintained alongside library updates
• Each breaking change commit includes an "Upgrade tip" section with migration examples: Upgrade tip: Change Raft::client_write_ff(.., responder) to Raft::client_write_ff(.., Some(responder))

You can always check the examples to see what application changes are needed for any upgrade.

[ariesdevil]

I think no need to worry and wait for 1.0, openraft has been widely used in many production environments. And even we introduce breaking changes, we provide detailed upgrade guide