GitHubを通じてFOSSライブラリを公開しています。これは大きなライブラリではありません。周りにコミュニティはありません。しかし、週に数十のユニークなクローンを取得します。
現在、このライブラリの設計変更を検討しています。これは単なる内部的なものではなく、APIに対する重要な変更です。それは「私の」ライブラリなので、先に進んでそれを実行することもできますが、この変更についてユーザーの意見を得たいと思います。
明らかに、私にはそれらの詳細がなく、積極的に尋ねることはできません。私は彼らの意見を投票しようとするアプローチをどのように提案しますか?
注:「サポート/オブジェクト」のバイナリ情報と、提案された変更のより長い評価の両方に興味があります。
最も直接的な方法は、そのようなことについて議論できるように、libのパブリックフォーラムを設定することです。
また、新しい「2.0試験的」ブランチを配置して、新しいデザインと新しいAPIがどのように見えるかを示すこともできます。また、APIドキュメントなどの適切な場所で、libの現在の「1.x」バージョン行に非推奨マークを追加します。
フォーラムの設定に手間がかかると思われる場合は、プロジェクトのメインページにメールアドレスを入力して、実験用ブランチのフィードバックに使用するように伝えてください。
妥当な時間内に十分なフィードバックが得られない場合は、先に進んでください。どのルートバージョン「2.0」が使用されるかを知らない人は、おそらくライブラリのバージョン1.0に満足しており、実際にはどのように興味がないのでしょうか。 2.0 APIは次のようになります。
ユーザーベースとの関わり方と、画期的な変更を加える方法の2つの問題があると思います。
2番目の答えは簡単です。メジャーバージョン番号をバンプします( セマンティックバージョニング )。
私はそれを単にそこに出すためのいくつかの議論があると思います。新しいユーザーは新しいバージョンから始めます。移行に問題があるユーザーは、問題を開く可能性があります。誰もが移行しない場合は、それも答えかもしれません。観察可能なユーザーの行動に関する利用可能な分析がどれほど優れているかに少し依存します。