QGIS 3.0-どのように、いつ、何を; それは意味します

私たちの多くは求めています。

いつQGIS 3.0がリリースされるのですか？

昨年（2015）、プロジェクトチームはQGIS 3.0がいつどのようにリリースされるのかを調査し始めました。 彼らは、 アニータ・グラーザー、QGIS 3.0をリリースする前に、計画のユーザーと開発者に明確に伝える予定でした。 彼らは最近、QGIS 3.0リリースに関する考慮事項のいくつかを提示しようとしました。投稿の最後に、私たちのアイデアを提示する機会があります。

なぜ3.0？

通常、メジャーバージョンは、ソフトウェアのAPIに大きな変更が加えられたときのために予約されています。 私たち自身の使用とサードパーティに提供されるサービスの両方でQGISに依存しているユーザーは数十万人であるため、この中断はQGISプロジェクトにとって簡単な決定ではありません。

時折APIを壊すことは、過去に行われた決定に改善のアプローチ、新しいライブラリと修正とアーキテクチャの更新に対応するために必要とされます。

APIを壊すの結果は何ですか？

もはや新しいAPIとの互換性がないとこれらの著者がしなければならないだろう開発のプラグインの数百人を破ることができQGIS 3.0におけるAPIのこの違反は、それが大きな影響を与えることになるということである一つの理由、新しいAPIとの互換性を保証するための開発のレビュー

必要な変更の範囲は、主に依存します。

• 多くのAPIの変更は、現在の機能に影響を与えます。
  どのように多くのポイントのプラグインの作成者は変更となるAPIの部品を使用していました。

• 3.0への主な変更点は何ですか？

3.0での変化を探している4つの主要分野があります。

QT4更新にQt5： これは、QGISがトップレベルで構築されているライブラリの基本セットです。プラットフォームのCORE機能レベルについて説明します。 QTは、メモリ管理、接続操作、およびグラフィックス管理を実行するためのライブラリも提供します。 Qt4（QGISが現在基づいている）は現在Qtライブラリメンテナによって開発されておらず、一部のプラットフォーム（OS Xなど）で機能の問題があり、バイナリバージョン（Debianテストや次のDebianリリースなど）の管理がさらに簡単になる可能性があります"ストレッチ"）。 QGISをQT5に導入するプロセスには、すでに重要な進歩があり（主にMatthias Kuhnが行ったこと）、Marco Bernasocchiと一緒に、完全にQT5に基づいたAndroid「QField」で煙を出します。 ただし、QGIS、特にWebブラウザウィジェット（主にComposerで使用され、QGISの他のいくつかの場所でも使用されます）に影響を与えるため、新しいQT5を起動して実行するにはいくつかの制限があります。

PyQt4更新にPyQt5： これらの変更は、QGIS PythonのAPIでQtのためのPython言語に関連する基づいています。 QT5 C ++ライブラリの変更が生じ、また、彼らは、Python QT5の新しいAPIの利点を取ることができるようにPyQt5のPythonライブラリに転送することが期待されます。
PythonのPythonの2.7 3の更新： 現在、すべてがPython2.7で実行されています。 Python 3はpythonの最新バージョンであり、そのプロジェクトを主導する人々によって推奨されています。 Python2はPython3とわずかに互換性がありません（QGIS2とQgis3の間の非互換性にほぼ比例します）。 多くの開発者は、python Python3をPython2とほぼ後方互換性のあるものにしましたが、後方互換性はそれほど大きくありません。
QGIS独自APIの改善： バージョン間でAPIの互換性を維持する際の問題の3.0つは、長期にわたって設計の選択に従わなければならないことです。 一連のマイナーリリースでAPIを壊さないようにQGISであらゆる努力が払われています。 現在サポートされていないAPIを使用してXNUMXのQGISバージョンをリリースすると、準拠していないAPIを修正することで、「クリーンハウス」を実現する機会が得られます。 あなたはの暫定的なリストを見ることができます 3.0は、APIへの変更を提案しました.

3.0のAPIの変更をサポートする方法

すでに述べたように、バージョン3.0はQGISバージョン2.xで機能しなくなり、現在のAPIに基づく多くのプラグイン、既存のアプリケーション、およびその他のコードが機能しなくなる可能性があります。 では、変更を軽減するために何ができるでしょうか。 Matthias Kuhn、JürgenFischer、Nyall Dawson、Martin Dobias、およびその他のトップ開発者は、次世代のライブラリと独自の内部APIに基づいてQGISコードベースを進化させながら、APIブレークの変更の数を軽減する方法を探しています。 QGISプロジェクト運営委員会の前回の会議で、私たちはさまざまな可能性を検討しました。 次の表は、Matthias Kuhnが丁寧に要約した内容と、この記事で部分的に文字変換を試みた内容をまとめたものです。 彼らは自身のブログ上で公開しました:

提案マティアスについて注意するには、2つの重要な点があります。

最初の段階では仕事はQt2、PyQt5とPython 5をサポートする、Pythonの3.0を使用して4.xサポートQT4、PyQt2.7を完了するために、直列に行われます。 これは、第1段階で行われたすべての変更は、以前のバージョン2.xと互換性があるであろうことを意味します。 QT4、PyQt5、Pythonの5に対してコンパイル時に古いAPI PyQt3.0はまだ特に使用することができるように組み込まれることになるPythonの機能が導入されます。 Qt4、PyQt4とPython 2.7に対してコンパイルQGISを使用することにより、互換性を壊さないでしょう。
第二相におけるそれは完全にQt3.0とPyQt2.7のサポートを含め、Pythonの4を削除し、新しいAPIを導入し、QGIS 4を生成するために働くだろう。 最初のフェーズに入るのpythonの新機能は、QGISの2.xバージョンのすべてのPythonコードと開発はQGISの3.xのバージョンで動作し続け考慮して、維持されます。 この相はまた、いくつかのプラグインを破ることQGIS APIの変化を導入することが期待されます。 対処するためにこれはバージョン2.x QGIS 3.x QGISのバージョンの移行を促進しようとするガイダンスAAの移行を提供します。

買主の危険負担

QGIS 3.0への移行はそれほど苦痛に聞こえることを確認するために頼まれるいくつかのトリックがあります。

• 1. S上記のアプローチは、プラグインでのpythonスクリプトの作業量を最小限に抑えようとしますが、これは必ずしも100％ではないことに注意してください。 コードを微調整する必要がある場合がほとんどであり、少なくともすべての場合において、コードが引き続き正しく機能することを確認するためにコードを修正する必要があります。
  2.この移行プロセスに自発的に時間を費やす開発者に支払うための正式に確立された財源はありません。 このため、プロセスの各部分にかかる時間の正確な時間枠を指定することは非常に困難になります。 この不確実性は、計画時に考慮に入れる必要があります。 もちろん、これを実現するための寄付は大歓迎です。
  3. QGIS 2.xシリーズの新機能に資金を提供している開発者や機関が存在する可能性があり、これが作業に影響を与える可能性があります。 これらのプロジェクトの計画と予算には、QGIS3.xプラットフォームへの移行に直面するための特定の割り当てを含める必要があります。
  4. QGISチームが「全体的な変更」に取り組んでいる場合、QGIS 3.0の継続的な更新により、QGISが不安定になり、絶えず変更される比較的短い時間があります。
  4.「進化的」な方法で開発する場合、3.0の開発に忠実な開発者グループが取り組んでいて、移植の準備ができていない限り、XNUMXの開発に時間がかかる可能性があります。

  提案

上記のすべての情報に照らして、アクションの2つのコースの一方が提案されています。

1提案：

暫定バージョン2.16をリリースしてから、バージョン3.0での作業を優先的に開始し、開発期間は8か月です。 バージョン2.16で行われた変更は、バージョン3.0との互換性を追求します（python3 / pytq5を参照）。

2提案：

QT3.0、Pythonの5とPyQt3.0の詳細延長期間ウィンドウで5たら突進と3.0で自分の仕事をするために、開発者に尋ねます。 2の準備ができるまで、通常の周波数で3.0.xバージョンを続行します。

代替案

別の提案がありますか？ QGISは、可能な代替案について知りたいと考えています。 提案を提出したい場合は、に送信してください tim@qgis.org 件名は「QGIS3.0提案」です。

従う必要があります QGISのブログ、どこからこの出版物は来ました。