That sounds fine to me.
On 23/02/2022 10:49, Konstantin Knauf wrote:
Hi Chesnay, Hi everyone,
I think the idea for the migration is the following (with the example of
ElasticSearch). I talked to Martijn offline.
1. ElasticSearch Connector is released from the core repository with the
Flink 1.15.0 release. No changes.
2. At the beginning of the Flink 1.16 release cycle the connector is
removed from `master` of the core repository. It remains on the
`release-1.15` branch and earlier release branches.
3. The connector code is "copied" over to the `master` branch of a
`flink-connector-elastic-search` repository. Bugfixes to the connector need
to go to both `release-1.15` and before in the core repository and `master`
of the external repository.
4. Once all the processes required to do a release in the
`flink-connector-elastic-search` are in place (docs integration, release
automation,...), we release flink-connector-elastic-search:3.0.0, which
will be compatible with Flink 1.15. At this point, users can choose whether
they use flink-connector-elastic-search:1.15.x (released from the core
repository) or flink-connector-elastic-search:3.0.0 already released from
the external repository with Flink 1.15. The documentation will already
advertise the one released from the external repository. This is the
"overlap" that Martijn mentioned.
5. From here onwards, the release cycle of the ElasticSearch Connector is
independent. There could be 3.1.0 and 3.0.1 etc. The compatibility matrix
will be part of the connector documentation.
6. If there is a patch release for Flink 1.15-, this will of course also
include flink-connector-elastic-search release from the core repository.
7. For Flink 1.16, there might or might not be a release of the
elastic-search-connector from the external repository. Depends on
compatibility.
I hope this clarifies it a bit and it makes sense to me.
It also makes sense to me to do this as soon as possible (probably once the
release-1.15 branch is cut) with the example of ElasticSearch. Afterwards
(hopefully still in the Flink 1.16 release cycle) we do the same for other
connectors like Kafka, Pulsar, Kinesis. I don't think it's feasible or
helpful to make it a condition that this happens for all connectors at the
same time.
Cheers and thanks,
Konstantin
On Sun, Feb 20, 2022 at 7:57 PM Chesnay Schepler <ches...@apache.org> wrote:
If we don't make a release, I think it would appear as partially
externalized (since the binaries are still only created with Flink core,
not from the external repository).
I'm wondering you are referring to when you say "it appear[s]". Users
don't know about it, and contributors can be easily informed about the
current state. Who's opinion are you worried about?
doing a release [means] that we have then completely externalized the
connector
In my mind the connector is completely externalized once the connector
project is complete and can act independently from the core repo. That
includes having all the code, working CI and the documentation being
integrated into the Flink website. And /then/ we can do a release. I
don't see how this could work any other way; how could we possibly argue
that the connector is externalized when development on the connector
isn't even possible in that repository?
There are also other connectors (like Opensearch and I believe RabbitMQ)
that will end up straight in their own repositories
Which is a bit of a different situation because here the only source of
this connector will have been that repository.
Would you prefer to remove a connector in a Flink patch release?
No. I think I misread your statement; when you said that there "is 1
release cycle where the connector both exists in Flink core and the
external repo", you are referring to 1.15, correct? (although this
should also apply to 1.14 so isn't it 2 releases...?)
How I understood it was that we'd keep the connector around until 1.16,
which would obviously be terrible.
On 19/02/2022 13:30, Martijn Visser wrote:
Hi Chesnay,
I think the advantage of also doing a release is that we have then
completely externalized the connector. If we don't make a release, I
think
it would appear as partially externalized (since the binaries are still
only created with Flink core, not from the external repository). It would
also mean that in our documentation we would still point to the binary
created with the Flink core release.
There are also other connectors (like Opensearch and I believe RabbitMQ)
that will end up straight in their own repositories. Since we also would
like to document those, I don't think the situation will be messy. We can
also solve it with an information hint in the documentation.
With regards to point 6, do you have an alternative? Would you prefer to
remove a connector in a Flink patch release?
Best regards,
Martijn
On Fri, 18 Feb 2022 at 16:17, Chesnay Schepler<ches...@apache.org>
wrote:
Why do you want to immediately do a release for the elasticsearch
connector? What does that provide us?
I'd rather first have a fully working setup and integrated documentation
before thinking about releasing anything.
Once we have that we may be able to externalize all connectors within 1
release cycle and do a clean switch; otherwise we end up with a bit of a
messy situation for users where some connectors use version scheme A and
others B.
I also doubt the value of 6). They'll have to update the version anyway
(and discover at some point that the version scheme has changed), so I
don't see what this makes easier.
On 18/02/2022 14:54, Martijn Visser wrote:
Hi everyone,
As a follow-up to earlier discussions [1] [2] to externalize the
connectors
from the Flink repository, I would like to propose a plan to
externalize
these connectors. The goal of this plan is to start with moving
connectors
to its own repositories without introducing regressions for connector
developers.
The plan is as follows:
1. A new repository is requested for a connector.
2. The code for that connector is moved to its individual repository,
including the commit history
3. Any first release made for a connector in an external connector
repository starts with major version 3, so 3.0.0. The reason for that
is
that we want to decouple the Flink releases from a connector release.
If
we
would start with major version 2, it could cause some confusion because
people could think a Flink 2.0 has been released. This does mean that
each
connector needs to have a compatibility matrix generated, stating which
version number of the connector is compatible with the correct Flink
version.
4. The group id and artifact id for the connector will remain the same,
only the version is different.
5. The connector dependencies on the Flink website are updated to point
to
the newly released connector artifact.
6. If a connector is moved, there is one release cycle where there will
be
binary releases for that connector in both Flink core and from the
connector repository. This is to make Flink users who are upgrading
slightly easier. We will have to make a note in the release notes that
a
connector has been moved and that a user should update any references
from
the original connector artifact (from the Flink connector) to the new
connector artifact (from the external conenctor version)
We propose to first try to execute this plan for the Elasticsearch
connector as follows:
1. We wait until the Flink 1.15 release branch is cut
2. When that's done, the Elasticsearch code (including commit history)
from
Flink's 1.15 release branch will be moved to the
flink-connector-elasticsearch main branch.
3. When Flink 1.15 is released, we will also release an Elasticsearch
connector for the external connector repository with version 3.0.0.
4. Bugfixes or improvements will be made first pointing to the external
connector repository and will be cherry-picked back to the release-1.15
branch in the Flink core repository.
5. The Elasticsearch code, test etc will be removed from the master
branch
in the Flink core repository and dropped with Flink 1.16
Looking forward to your thoughts on this!
Best regards,
Martijn Visser
https://twitter.com/MartijnVisser82
[1]https://lists.apache.org/thread/bywh947r2f5hfocxq598zhyh06zhksrm
[2]https://lists.apache.org/thread/bk9f91o6wk66zdh353j1n7sfshh262tr
