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

[hailin0]

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]

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

[dailai]

LGTM

[liugddx]

Will this affect existing tasks?

[hailin0]

Compatible with old versions

cc @liugddx

[Carl-Zhou-CN]

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

[hailin0]

PTAL

[liunaijie]

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]

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

[Carl-Zhou-CN]

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

+1

[hailin0]

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]

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]

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.

[hailin0]

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.

Added notes.