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 and not 1.14.x? I would be inclined to support the latest 2 minor Flink versions (major.minor.patch) given that we only have 1 active major Flink version. Danny On Wed, Oct 12, 2022 at 2:12 PM Chesnay Schepler <ches...@apache.org> 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. >
