🚀 Direction and Priorities toward v1.0.0

[electrohyun]

Context

With v0.4.2 released, Smocket has entered the stretch toward its first stable release.

Before defining the remaining work for v1.0.0, this discussion steps back to consider what Smocket should prioritize and what promises a stable release should make. It serves both as a working note for the maintainers and as an invitation for feedback from the community.

The goal is not to present every decision as final. It is to make the reasoning behind the roadmap visible, gather real-world use cases and concerns, and eventually publish a clear account of what Smocket values on the way to v1.0.0.

Lenses under consideration

These are starting points for discussion. They are not yet finalized principles, and they are not necessarily equally weighted.

Lens	Question
Fidelity	Does Smocket reproduce the same observable results as real Socket.IO?
Extensibility	Can Smocket grow without breaking that fidelity?
Reliability	Are those results continuously verified as Socket.IO and Smocket change?
Productivity	Does Smocket reduce the cost of writing and maintaining Socket.IO tests?
Sustainability	Can Smocket's promises and development model be maintained over the long term?

These lenses may reinforce or compete with one another. Part of this discussion is deciding which trade-offs are acceptable and which guarantees must remain non-negotiable.

Community contributions are welcome

For a durable guide to choosing between issues, Discussions, and documentation, see the contributing guide.

Community experience is an important input to Smocket's direction. If you have used Socket.IO or Smocket in a real project, you can help through the following contribution paths.

• If Smocket does not yet support a Socket.IO behavior that your project needs, please open a Feature Request issue. Include the concrete use case and the relevant Socket.IO API or behavior.

  • Helps improve Fidelity.

• If Smocket produces a different observable result from real Socket.IO, please open a Bug Report issue. Include the versions used, expected result, actual result, and a minimal reproduction when possible.

  • Helps improve Fidelity and Reliability.

• If the current API requires repetitive setup, workaround code, or unnecessary maintenance, describe the experience in this discussion. If you already have a specific change in mind, you may open a Feature Request issue.

  • Helps improve Productivity.

• If an adapter, test utility, or other convenience feature would help without changing Socket.IO behavior, describe the use case in this discussion or open a Feature Request issue. Please also explain how the proposal could preserve compatibility with Socket.IO.

  • Helps improve Extensibility and Productivity.

• If the current tests, CI, compatibility reports, or development processes are not sufficient for you to trust Smocket, describe what additional evidence or process would help in this discussion.

  • Helps improve Reliability and Sustainability.

• If documentation is difficult to find, incomplete, or prevents you from contributing, please open a Documentation issue.

  • Helps improve Productivity and Sustainability.

Concrete use cases, missing behaviors, minimal reproductions, and examples from existing Socket.IO test suites are particularly helpful when deciding what belongs in the v1.0.0 roadmap.

Expected outcomes

This discussion should lead to:

• a written statement of Smocket's direction and priorities;
• a public roadmap toward v1.0.0;
• public reports in both a static Markdown document and an interactive site page;
• focused follow-up issues for work accepted into the roadmap.

TODO

• Document what the five lenses mean for Smocket's development and decision-making (development lenses).
• Document how to contribute through issues, Discussions, and documentation (#215; contributing guide).
• Publish a public roadmap toward v1.0.0 (#216; roadmap).
• Correct the confirmed compatibility gaps tracked for v0.5.0 (#228, #229, #230, #231, #232, #233, and #234).
• Resolve the public-surface decisions required before the v1 guarantee is finalized (#178, #235, #236, #237, and #238).
• Strengthen the maintained application workflow (#113) and validate it across an independent published-package boundary (#208).
• Publish the application case study and its static report and interactive report (#218).
• Publish the synchronized v0.5.0 pair and complete the repository-owned release chain (#284, #320).
• Complete the final v1.0.0 candidate review (Scheduled).