This approach makes sense to me. If Spark K8s operator is aligned with Spark versions, for example, it uses 4.0.0 now. Because these JIRA tickets are not actually targeting Spark 4.0.0, it will cause confusion and more questions, like when we are going to cut Spark release, should we include Spark operator JIRAs in the release note, etc.
So I think an independent version number for Spark K8s operator would be a better option. If there are no more options or comments, I will create a vote later to create new "Versions" in Apache Spark JIRA. Thank you all. On Wed, Apr 10, 2024 at 12:20 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. > --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
