Of course we can (and will).
That will happen at a later time once we get a bit of use out of it to
iterate faster.
On 20/10/2022 18:23, Steven Wu wrote:
Chesnay, thanks for the write-up. very helpful!
Regarding the parent pom, I am wondering if it can be published to the
Chesnay, thanks for the write-up. very helpful!
Regarding the parent pom, I am wondering if it can be published to the
`org.apache.flink` group?
io.github.zentol.flink
flink-connector-parent
1.0
On Mon, Oct 17, 2022 at 5:52 AM Chesnay Schepler wrote:
>
>
https://cwiki.apache.org/confluence/display/FLINK/Externalized+Connector+development
On 17/10/2022 13:13, Chesnay Schepler wrote:
The vote has passed unanimously.
+1 Votes:
- Danny (binding)
- Martijn (binding)
- Ferenc (non-binding)
- Thomas (binding)
- Ryan (non-binding)
- Jing (non-binding)
The vote has passed unanimously.
+1 Votes:
- Danny (binding)
- Martijn (binding)
- Ferenc (non-binding)
- Thomas (binding)
- Ryan (non-binding)
- Jing (non-binding)
- Matthias (binding)
I will now document this in the wiki and start working on the release
scripts.
On 12/10/2022 15:12,
Thanks for the comprehensive explanation. It is clear now.
Best regards,
Jing
On Fri, Oct 14, 2022 at 9:51 AM Matthias Pohl
wrote:
> Ok, a bit of back-and-forth reading. :-D Thanks for the example. It sounds
> reasonable.
>
> +1 (binding)
>
> On Thu, Oct 13, 2022 at 8:33 PM Chesnay Schepler
>
Ok, a bit of back-and-forth reading. :-D Thanks for the example. It sounds
reasonable.
+1 (binding)
On Thu, Oct 13, 2022 at 8:33 PM Chesnay Schepler wrote:
> I will write this all down in the wiki once the vote is over, but here
> are some example.
>
>
> Let's start out with a happy-case
I will write this all down in the wiki once the vote is over, but here
are some example.
Let's start out with a happy-case scenario with one connector supporting
the last 2 Flink versions.
This will commonly be the scenario for connectors when they have been
externalized:
v1: 1.14-1.15
+1 and I would suggest giving a concrete example to explain 4) support. It
is still not quite easy to understand the text. Not many (future) connector
developers could join this discussion. It is better to make it as clear as
possible at the beginning than spend more time explaining multiple
+1 non-binding! I've been following (and generally agreeing) with the
thread -- it's a perfectly reasonable way to start, and I'm sure we can
adjust the process if it turns out to be unsuitable or unexpected as the
connectors evolve in their external repositories.
On Thu, Oct 13, 2022 at 12:37
+1 (binding) for the vote and thanks for the explanation
On Thu, Oct 13, 2022 at 5:58 AM Chesnay Schepler wrote:
> @Thomas:
> Version-specific modules that either contain a connector or shims to
> support that Flink version.
> Alternatively, since the addition of such code (usually) goes beyond
@Thomas:
Version-specific modules that either contain a connector or shims to
support that Flink version.
Alternatively, since the addition of such code (usually) goes beyond a
patch release you'd create a new minor version and could have that only
support the later version.
On 13/10/2022
I mean minor. I always get confused on the Flink side because we use
"major" instead of "minor" releases in many places.
On 12/10/2022 20:18, Danny Cranmer wrote:
Thanks for the concise summary Chesnay.
+1 from me (binding)
Just one clarification, for "3.1) The Flink versions supported by
"Branches are not specific to a Flink version. (i.e., no v3.2-1.15)"
Sorry for the late question. I could not find in the discussion thread how
a connector can make use of features of the latest Flink version that were
not present in the previous Flink version, when branches cannot be Flink
+1 from my side (non-binding)
Best,
F
--- Original Message ---
On Wednesday, October 12th, 2022 at 15:47, Martijn Visser
wrote:
>
>
> +1 (binding), I am indeed assuming that Chesnay meant the last two minor
> versions as supported.
>
> Op wo 12 okt. 2022 om 20:18 schreef Danny
+1 (binding), I am indeed assuming that Chesnay meant the last two minor
versions as supported.
Op wo 12 okt. 2022 om 20:18 schreef Danny Cranmer
> Thanks for the concise summary Chesnay.
>
> +1 from me (binding)
>
> Just one clarification, for "3.1) The Flink versions supported by the
>
Thanks for the concise summary Chesnay.
+1 from me (binding)
Just one clarification, for "3.1) The Flink versions supported by the
project (last 2 major Flink versions) must be supported.". Do we actually
mean major here, as in Flink 1.x.x and 2.x.x? Right now we would only
support Flink 1.15.x
Since the discussion
(https://lists.apache.org/thread/mpzzlpob9ymkjfybm96vz2y2m5fjyvfo) has
stalled a bit but we need a conclusion to move forward I'm opening a vote.
Proposal summary:
1) Branch model
1.1) The default branch is called "main" and used for the next major
iteration.
1.2)
17 matches
Mail list logo
