こんにちは、komutanさんの方の更新が続いていて良かったです。
私の方のMeCab.DotNetの方も、主に環境面でのissueについて更新を行っていますが、komutanさんの方の変更に追従できていなくて、どうしようかと思っています。いっそのこと、こちらのプロジェクトとの統合を考えてみたらどうだろうかと考え、まずは意見を聞きたくてissueを立てました。
MeCab.DotNetは、そもそも私がとあるイベント向けに.NET Core環境で使いたくて移植した、という経緯があったのですが、公開後、海外の方にも使われていることが分かり、（主に開発環境面での更新、例えば.NET Coreの新しいバージョンが出たなどで困らないよう）半ば義務感で更新を続けている状況です。
（イベントについては長文ですが私のブログにまとめています）
いくつか私的なプロジェクト（主に非公開）で使用しているのですが、形態素解析自体の知識があるわけではないので、あくまで前述の範囲での更新となってしまっているのが気になっています。恐らくは、コア部分の機能改善についてはkomutanさんの方が進んでいると思いますので、例えば現在のように開発環境面での更新や機能強化という点で協力できる部分があると思います。
そこで、2つのプロジェクトの統合を考えたのですが、別々にforkしていた方が開発がやりやすいとか何か理由があるようでしたら、それはそれでも一向に構いませんので、そのように言って頂ければと思います。
統合した場合の問題点について、まだあまり深く考えていませんが:
- ソースコードの統合: 何とか頑張ってやる :)
- 外部インターフェイスの問題としては、一番大きなのは名前空間かなと思います。
- 私案では、しばらく2つの名前空間のどちらでも参照できるような構造をとって、Obsoleteつけるなどして、最終的にどちらかに移行するのが良いかなと思います。
- NuGetパッケージ: 上記のようなダブルインターフェイス定義されたライブラリを、別々のパッケージで（中身は同じで）配布しつつ、Obsoleteを付けて、最終的にどちらかに統一するという方法を考えます。
- メソッドやプロパティの一部の（同居できない）非互換があれば、そこはbreaking changeで妥協する。
とりあえず、今思いついていることは書き出してみましたが、何か意見があればお願いします。
こんにちは、komutanさんの方の更新が続いていて良かったです。
私の方のMeCab.DotNetの方も、主に環境面でのissueについて更新を行っていますが、komutanさんの方の変更に追従できていなくて、どうしようかと思っています。いっそのこと、こちらのプロジェクトとの統合を考えてみたらどうだろうかと考え、まずは意見を聞きたくてissueを立てました。
MeCab.DotNetは、そもそも私がとあるイベント向けに.NET Core環境で使いたくて移植した、という経緯があったのですが、公開後、海外の方にも使われていることが分かり、（主に開発環境面での更新、例えば.NET Coreの新しいバージョンが出たなどで困らないよう）半ば義務感で更新を続けている状況です。
（イベントについては長文ですが私のブログにまとめています）
いくつか私的なプロジェクト（主に非公開）で使用しているのですが、形態素解析自体の知識があるわけではないので、あくまで前述の範囲での更新となってしまっているのが気になっています。恐らくは、コア部分の機能改善についてはkomutanさんの方が進んでいると思いますので、例えば現在のように開発環境面での更新や機能強化という点で協力できる部分があると思います。
そこで、2つのプロジェクトの統合を考えたのですが、別々にforkしていた方が開発がやりやすいとか何か理由があるようでしたら、それはそれでも一向に構いませんので、そのように言って頂ければと思います。
統合した場合の問題点について、まだあまり深く考えていませんが:
とりあえず、今思いついていることは書き出してみましたが、何か意見があればお願いします。