[Feature][Core] Rename `result_table_name`/`source_table_name` to `plugin_input/plugin_output`

apache / seatunnel

SeaTunnel is a next-generation super high-performance, distributed, massive data integration tool.

https://seatunnel.apache.org/

Apache License 2.0

8.05k stars 1.83k forks source link

[Feature][Core] Rename `result_table_name`/`source_table_name` to `plugin_input/plugin_output` #8072

Open hailin0 opened 5 days ago

hailin0 commented 5 days ago

Purpose of this pull request

close #8062

Does this PR introduce any user-facing change?

How was this patch tested?

Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:
1. Update plugin-mapping.properties and add new connector information in it
2. Update the pom file of seatunnel-dist
3. Add ci label in label-scope-conf
4. Add e2e testcase in seatunnel-e2e
5. Update connector plugin_config
[ ] Update the release-note.

Hisoka-X commented 4 days ago

This is a big change. cc @TyrantLucifer @liugddx @liunaijie @dailai @Carl-Zhou-CN

liugddx commented 3 days ago

Will this affect existing tasks?

Carl-Zhou-CN commented 2 days ago

@hailin0 Do we need to keep a few test cases and end-to-end tests for backward compatibility with the old version？

hailin0 commented 1 day ago

PTAL

liunaijie commented 1 day ago

This is a big change, even it's backward compatibility with the old version, but how many version should we keep backward, all the time or like 2 or 3 versions?

How about add a upgrade note on each release version, in this page, introduce how to upgrade from old version (which is the minimum version). which feature (parameters) is deprecated, moreover we can introduce the features, fixed bug.

Now we have the release-node, but it's not enough.

WDYT

Hisoka-X commented 23 hours ago

how many version should we keep backward, all the time or like 2 or 3 versions

I think we should keep it indefinitely, not just for 2 or 3 versions. Perhaps after one or two years, we can revisit it to decide whether to keep or remove it, as keeping it poses no burden to us. However, we should mention in the documentation that the use of result_table_name and source_table_name is no longer recommended. cc @hailin0

How about add a upgrade note on each release version, in this page, introduce how to upgrade from old version (which is the minimum version). which feature (parameters) is deprecated, moreover we can introduce the features, fixed bug.

Carl-Zhou-CN commented 22 hours ago

how many version should we keep backward, all the time or like 2 or 3 versions

I think we should keep it indefinitely, not just for 2 or 3 versions. Perhaps after one or two years, we can revisit it to decide whether to keep or remove it, as keeping it poses no burden to us. However, we should mention in the documentation that the use of result_table_name and source_table_name is no longer recommended. cc @hailin0

How about add a upgrade note on each release version, in this page, introduce how to upgrade from old version (which is the minimum version). which feature (parameters) is deprecated, moreover we can introduce the features, fixed bug.

+1

hailin0 commented 18 hours ago

This is a big change, even it's backward compatibility with the old version, but how many version should we keep backward, all the time or like 2 or 3 versions?

How about add a upgrade note on each release version, in this page, introduce how to upgrade from old version (which is the minimum version). which feature (parameters) is deprecated, moreover we can introduce the features, fixed bug.

Now we have the release-node, but it's not enough.

WDYT

Yes, this is what is still missing

hailin0 commented 18 hours ago

how many version should we keep backward, all the time or like 2 or 3 versions

I think we should keep it indefinitely, not just for 2 or 3 versions. Perhaps after one or two years, we can revisit it to decide whether to keep or remove it, as keeping it poses no burden to us. However, we should mention in the documentation that the use of result_table_name and source_table_name is no longer recommended. cc @hailin0

How about add a upgrade note on each release version, in this page, introduce how to upgrade from old version (which is the minimum version). which feature (parameters) is deprecated, moreover we can introduce the features, fixed bug.

+1

@Hisoka-X Current, an outdated parameter warning will be printed in the log.

Hisoka-X commented 18 hours ago

Current, an outdated parameter warning will be printed in the log.

We should metion it in doc too, let users to consciously change expired configurations. Doc more important than log.