You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tsfile.apache.org by ColinLee <sh...@163.com> on 2026/07/30 08:12:11 UTC
[VOTE] C++ third-party dependency management policy
Hi all,
Following the discussion in:
https://lists.apache.org/thread/1ssk1rot302cx88pkt3rvzxjr19kpppr
I would like to call a vote on the third-party dependency management
policy for the TsFile C++ module.
The proposal is:
1. Introduce the following global CMake option:
TSFILE_DEPENDENCY_SOURCE=AUTO|SYSTEM|BUNDLED
- AUTO (default): Prefer compatible system dependencies and fall
back to bundled dependencies when unavailable.
- SYSTEM: Use only dependencies supplied by the system or package
manager. Configuration should fail with a clear error when a
required dependency is missing or incompatible.
- BUNDLED: Build pinned dependency versions managed by the TsFile
build system.
2. BUNDLED does not imply maintaining complete upstream source trees
in the TsFile repository. Normally, dependency versions, source
archive URLs, and SHA256 checksums should be recorded centrally.
An offline cache or pre-download mechanism should also be provided.
3. Keeping third-party source code directly in the repository is an
exception. Such inclusion requires community review and should be
limited to small and stable code whose license permits
redistribution. Its origin, version or commit, trimming scope,
local modifications, and license information must be documented.
4. Implementation will be incremental:
- Audit existing C++ dependencies and correct their source, version,
license, and local-modification metadata.
- Introduce the dependency-source framework.
- Migrate dependencies through separate pull requests.
- Add CI coverage for SYSTEM, BUNDLED, AUTO, and offline builds.
The initial inventory covers ANTLR4 C++ runtime, Snappy, LZ4, lzokay,
SIMDe, zlib, and the test-only GoogleTest archive. It has also identified
some metadata and root LICENSE entries that need to be completed or
corrected. These will be handled in the first incremental pull request.
This vote establishes the policy and implementation direction only.
Each code change and each dependency decision will still be reviewed
through its own pull request.
Please vote:
[ ] +1 Approve the proposal
[ ] 0 No opinion
[ ] -1 Do not approve (please provide a reason)
I vote +1.
This vote will remain open for at least 72 hours.
Thanks,
Colin
Re: [VOTE] C++ third-party dependency management policy
Posted by Tian Jiang <jt...@163.com>.
+1
To support various scenarios and continuously boost its performance,
it is expected that TsFile will introduce more encoding/compression algorithms,
eco-system integration, etc.
As a result, the dependency management will be a critical issue.
Also, to support different deployment requirements, like online and offline build,
we cannot struggle on a single way.
The flexibility shown by the proposal may be a great relief.
Best,
Tian Jiang
---- Replied Message ----
| From | ColinLee<sh...@163.com> |
| Date | 7/30/2026 16:12 |
| To | dev<de...@tsfile.apache.org> |
| Subject | [VOTE] C++ third-party dependency management policy |
Hi all,
Following the discussion in:
https://lists.apache.org/thread/1ssk1rot302cx88pkt3rvzxjr19kpppr
I would like to call a vote on the third-party dependency management
policy for the TsFile C++ module.
The proposal is:
1. Introduce the following global CMake option:
TSFILE_DEPENDENCY_SOURCE=AUTO|SYSTEM|BUNDLED
- AUTO (default): Prefer compatible system dependencies and fall
back to bundled dependencies when unavailable.
- SYSTEM: Use only dependencies supplied by the system or package
manager. Configuration should fail with a clear error when a
required dependency is missing or incompatible.
- BUNDLED: Build pinned dependency versions managed by the TsFile
build system.
2. BUNDLED does not imply maintaining complete upstream source trees
in the TsFile repository. Normally, dependency versions, source
archive URLs, and SHA256 checksums should be recorded centrally.
An offline cache or pre-download mechanism should also be provided.
3. Keeping third-party source code directly in the repository is an
exception. Such inclusion requires community review and should be
limited to small and stable code whose license permits
redistribution. Its origin, version or commit, trimming scope,
local modifications, and license information must be documented.
4. Implementation will be incremental:
- Audit existing C++ dependencies and correct their source, version,
license, and local-modification metadata.
- Introduce the dependency-source framework.
- Migrate dependencies through separate pull requests.
- Add CI coverage for SYSTEM, BUNDLED, AUTO, and offline builds.
The initial inventory covers ANTLR4 C++ runtime, Snappy, LZ4, lzokay,
SIMDe, zlib, and the test-only GoogleTest archive. It has also identified
some metadata and root LICENSE entries that need to be completed or
corrected. These will be handled in the first incremental pull request.
This vote establishes the policy and implementation direction only.
Each code change and each dependency decision will still be reviewed
through its own pull request.
Please vote:
[ ] +1 Approve the proposal
[ ] 0 No opinion
[ ] -1 Do not approve (please provide a reason)
I vote +1.
This vote will remain open for at least 72 hours.
Thanks,
Colin
Re: [VOTE] C++ third-party dependency management policy
Posted by Haonan Hou <ha...@apache.org>.
+1
Looks good to me.
BR,
Haonan
On 2026/07/30 08:12:11 ColinLee wrote:
> Hi all,
>
>
> Following the discussion in:
>
>
> https://lists.apache.org/thread/1ssk1rot302cx88pkt3rvzxjr19kpppr
>
>
> I would like to call a vote on the third-party dependency management
> policy for the TsFile C++ module.
>
>
> The proposal is:
>
>
> 1. Introduce the following global CMake option:
>
>
> TSFILE_DEPENDENCY_SOURCE=AUTO|SYSTEM|BUNDLED
>
>
> - AUTO (default): Prefer compatible system dependencies and fall
> back to bundled dependencies when unavailable.
>
>
> - SYSTEM: Use only dependencies supplied by the system or package
> manager. Configuration should fail with a clear error when a
> required dependency is missing or incompatible.
>
>
> - BUNDLED: Build pinned dependency versions managed by the TsFile
> build system.
>
>
> 2. BUNDLED does not imply maintaining complete upstream source trees
> in the TsFile repository. Normally, dependency versions, source
> archive URLs, and SHA256 checksums should be recorded centrally.
> An offline cache or pre-download mechanism should also be provided.
>
>
> 3. Keeping third-party source code directly in the repository is an
> exception. Such inclusion requires community review and should be
> limited to small and stable code whose license permits
> redistribution. Its origin, version or commit, trimming scope,
> local modifications, and license information must be documented.
>
>
> 4. Implementation will be incremental:
>
>
> - Audit existing C++ dependencies and correct their source, version,
> license, and local-modification metadata.
> - Introduce the dependency-source framework.
> - Migrate dependencies through separate pull requests.
> - Add CI coverage for SYSTEM, BUNDLED, AUTO, and offline builds.
>
>
> The initial inventory covers ANTLR4 C++ runtime, Snappy, LZ4, lzokay,
> SIMDe, zlib, and the test-only GoogleTest archive. It has also identified
> some metadata and root LICENSE entries that need to be completed or
> corrected. These will be handled in the first incremental pull request.
>
>
> This vote establishes the policy and implementation direction only.
> Each code change and each dependency decision will still be reviewed
> through its own pull request.
>
>
> Please vote:
>
>
> [ ] +1 Approve the proposal
> [ ] 0 No opinion
> [ ] -1 Do not approve (please provide a reason)
>
>
> I vote +1.
>
>
> This vote will remain open for at least 72 hours.
>
>
> Thanks,
> Colin