testcontainers / testcontainers/testcontainers-python
Discussion: Officially supported version ranges
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 2.3k
- フォーク
- 386
- 平均マージ
- 4時間 40分
- マージ済み PR(30日)
- 1
説明
I think we should have a larger discussion in this repo on what we actually want to support in custom container setups, as making the implementation support all versions since the beginning of time will lead to a lot of nasty workarounds while only catering to a (presumably) small portion of people that want to use legacy versions.
There has already been some discussion happening here and here.
We need to ask ourselves the following question, and probably a lot more:
- Should we support the latest version?
- Should we only support officially supported versions of the service?
- What repositories should we support? What if there are changes between the images in the different repositories?
- If there is no officially supported version range, what do we do?
Having support for an explicit version range would also require us to cap the support on the latest release, and check / update the version range on every new release (otherwise we cannot know if the new versions are actually compatible or not, and it would be worse to say incorrectly that we support something than not supporting it).
My personal take on this is that in order to reduce the amount of extra / duplicated / workarounds in code to support multiple version ranges, we should be quite restrictive on what versions we do officially support. E.g. for ElasticSearch we could support the official versions ^8.8.1+ and ^7.17.10 (found here), but nothing more. For images like Keycloak we should be even more restrictive in our officially supported version ranges, as it is very lacking in documentation on what actually is maintained, lots of breaking changes between versions etc., and only support the latest major version (v22.x as of writing)
Supporting latest is a bad idea, as we can see from the tests as bad images are published quite frequently before getting a quick/hotfix immediately after. At the very least, no tests should use latest for testing, as it destroys the reproducibility.
What do you guys think?
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まずプルリクエスト #369 と #357 の議論を確認し、その後、現在リポジトリのテストでカバーされているサービスイメージとバージョン範囲を一覧化します。プロジェクトに、合意され文書化されたサポートポリシー、再現可能な最新ではないテストバージョン、新しいリリースでサポート状況を確認するための明確なプロセスが整備された時点で、作業は完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- docker, python
- 領域
- devops, testing
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100