19w36aで、Mojangはランチャー用にclient.jsonで難読化データ参照を出荷しました。 多くの人々は、この時点から、糸は時代遅れになるかもしれないと信じています。
ただし、糸について考慮すべき点がまだいくつかあります。
Asieは不和で、mojangがこのプロガードのものをリリースしたのはおそらく糸の仕事のためだと言っています。 mojangがこのデータをいつか撤回しないことを保証することはできません。 それが起こった場合、ファブリックコミュニティは破壊されます。
asieが指摘したように、yarnはMojangプロガードデータから何も使用できません。 これにより、mojangのような名前ではなく、クラスの正確な名前を作成するという目的がより強固になると思います。
他に考慮すべき点はありますか? お待ちしております。
ヤーンは、マッピングを誰でも使用できるように、無制限のライセンスで正確なマッピングを持つように作成されていました。
現在のライセンスでは、これはMojangマッピングには当てはまりません。
したがって、現在の状態では、MCPマッピングの場合と同様に、Mojangマッピングを見ることなく、以前と同じようにyarnを更新し続けると言います。
ライセンスが緩んだり明確になったりした場合でも、パラメータ名とJavadoc用にライセンスを保持する必要があります。
私はNeunに完全に同意します。 現在のライセンスは、Yarnが作成されたのとは正反対の目標を達成します。 そのまま切り替えると、MCPと競合するよりもさらに危険な合法的な地雷原に身を置くことになります。 ライセンスがMicrosoftではなくMojangの名前であった場合、私は違った感じをするかもしれませんが、リスクを上回る切り替えの利点はわかりません。
糸は常にMojangマッピングの影響を受けないようにする必要があると思います。 将来、Modでマッピングを使用する許可をMojangから取得した場合、パラメーターマッピングとjavadocsの追加は、yarnではなく別のプロジェクトで行う必要があります。
これで、javadocとパラメータの両方を取得できます。 私たちは良いはずです:rocket:
最も参考になるコメント
ヤーンは、マッピングを誰でも使用できるように、無制限のライセンスで正確なマッピングを持つように作成されていました。
現在のライセンスでは、これはMojangマッピングには当てはまりません。
したがって、現在の状態では、MCPマッピングの場合と同様に、Mojangマッピングを見ることなく、以前と同じようにyarnを更新し続けると言います。
ライセンスが緩んだり明確になったりした場合でも、パラメータ名とJavadoc用にライセンスを保持する必要があります。