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, Chesnay Schepler wrote:
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) Remaining branches are called "vmajor.minor". (e.g., v3.2)
1.3) Branches are not specific to a Flink version. (i.e., no v3.2-1.15)
2) Versioning
2.1) Source releases: major.minor.patch
2.2) Jar artifacts: major.minor.match-flink-major.flink-minor
(This may imply releasing the exact same connector jar multiple times
under different versions)
3) Flink compatibility
3.1) The Flink versions supported by the project (last 2 major Flink
versions) must be supported.
3.2) How this is achived is left to the connector, as long as it
conforms to the rest of the proposal.
4) Support
4.1) The last 2 major connector releases are supported with only the
latter receiving additional features, with the following exceptions:
4.1.a) If the older major connector version does not support any
currently supported Flink version, then it is no longer supported.
4.1.b) If the last 2 major versions do not cover all supported Flink
versions, then the latest connector version that supports the older
Flink version /additionally /gets patch support.
4.2) For a given major connector version only the latest minor version
is supported.
(This means if 1.1.x is released there will be no more 1.0.x release)
I'd like to clarify that these won't be set in stone for eternity.
We should re-evaluate how well this model works over time and adjust
it accordingly, consistently across all connectors.
I do believe that as is this strikes a good balance between
maintainability for us and clarity to users.
Voting schema:
Consensus, committers have binding votes, open for at least 72 hours.
