为啥会出现多个版本？
Flink 社区本身迭代速度非常快，目前阿里云有一大波的人专职做 Flink 开源，另外还拥有活跃的社区贡献者，所以功能开发较快，bug 修复速度较快，几乎每 4 个月一个大版本，每个大版本之间迭代的功能非常多，代码变动非常大，API 接口变动也大，动不动就干翻自己了。
社区迭代快就快呗，为什么公司也要要不断跟着社区鼻子走？社区迭代快意味着功能多，修复的 bug 多，相对于早期版本意味着稳定性也高些。除了国内一二线公司有特别多的专职人去负责这块，大多数中小公司最简单最快捷体验到稳定性最高、功能性最多、性能最好的 Flink 版本无非是直接使用最新的 Flink 版本。举个例子：Flink SQL 从最早期（1.9）的功能、性能到目前 1.14，差别真的大很多，优化了特别多的地方，增强了很多功能。原先使用 Flink SQL 完成一个流处理任务非常麻烦，还不如直接写几十行代码来的快，目前我情愿写 SQL 去处理一个流任务。那么自然会跟着升级到新版本。
用户 A 问 Flink SQL 支持单独设置并行度吗？用户 B 问实时平台现在支持 Flink 1.13 版本的 Window TVF？这个要 Flink xxx 版本才能支持，要不你升级一下 Flink 版本到 xxx？这样就能支持了，类似的场景还有很多，对于中小公司的实时平台负责人来说，这无非最省事；对于大公司的负责实时开发的人来说，这无疑是一个噩梦，每次升级新版本都要将在老版本开发的各种功能都想尽办法移植到新版本上来，碰到 API 接口变动大的无非相当于重写了，或者将新版本的某些特别需要的功能通过打 patch 的方式打到老版本里面去。
新版本香是真的香，可是为啥有的人不用呢？问题就是，实时作业大多数是长期运行的，如果一个作业没啥错误，在生产运行的好好的，也不出啥故障，稳定性和性能也都能接受（并不是所有作业数据量都很大，会遇到性能问题），那么用户为啥要使用新版本？用户才不管你新版本功能多牛逼，性能多屌呢，老子升级还要改依赖版本、改接口代码、测试联调、性能测试（谁知道你说的性能提升是不是吹牛逼的）、稳定性测试（可能上线双跑一段时间验证），这些不需要时间呀，你叫我升级就升级，滚犊子吧，你知道我还有多少业务需求要做吗？
那么就落下这个场地了，又要使用新版本的功能去解决问题，老作业的用户跟他各种扯皮也打动不了他升级作业的版本，那么自然就不断的出现了多个版本了。
这样，如果不对版本做好规划，那么摊子就逐渐越来越大，越来越难收拾了？
那么该如何管理公司的 Flink 版本？如果管理和兼容多个 Flink 版本的作业提交？如何兼容 Jar 包和 SQL 作业的提交
怎么管理多个 Flink 版本的作业提交？
尽请期待下篇文章
