Cool, looks like we have two options here. Option 1: Spark Operator and Connect Go Client versioning independent of Spark, e.g. starting with 0.1.0. Pros: they can evolve versions independently. Cons: people will need an extra step to decide the version when using Spark Operator and Connect Go Client.
Option 2: Spark Operator and Connect Go Client versioning loosely related with Spark, e.g. starting with the Supported Spark version Pros: might be easy for beginning users to choose version when using Spark Operator and Connect Go Client. Cons: there is uncertainty how the compatibility will go in the future for Spark Operator and Connect Go Client regarding Spark, which may impact this version naming. Right now, Connect Go Client uses Option 2, but can change to Option 1 if needed. On Wed, Apr 10, 2024 at 6:19 AM Dongjoon Hyun <dongjoon.h...@gmail.com> wrote: > Ya, that would work. > > Inevitably, I looked at Apache Flink K8s Operator's JIRA and GitHub repo. > > It looks reasonable to me. > > Although they share the same JIRA, they choose different patterns per > place. > > 1. In POM file and Maven Artifact, independent version number. > <version>1.8.0</version> > > 2. Tag is also based on the independent version number > https://github.com/apache/flink-kubernetes-operator/tags > - release-1.8.0 > - release-1.7.0 > > 3. JIRA Fixed Version is `kubernetes-operator-` prefix. > https://issues.apache.org/jira/browse/FLINK-34957 > > Fix Version/s: kubernetes-operator-1.9.0 > > Maybe, we can borrow this pattern. > > I guess we need a vote for any further decision because we need to create > new `Versions` in Apache Spark JIRA. > > Dongjoon. > >
