A related question - what is the expected release cadence? At least for the next 12-18 months? Since this is a new subproject, I am personally hoping it would have a faster cadence at first, maybe one a month or once every couple of months... If so, that would affect versioning. Also, if it uses semantic versioning, since it is early for the subproject it might have a few releases with breaking changes until its own API, defaults, behavior becomes stable, so again, having its own versioning might help. Just my two cents, Ofir ________________________________ From: L. C. Hsieh <vii...@gmail.com> Sent: Wednesday, April 10, 2024 6:14 PM To: Dongjoon Hyun <dongjoon.h...@gmail.com> Cc: dev@spark.apache.org <dev@spark.apache.org> Subject: [External] Re: Versioning of Spark Operator
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
