[DISCUSS] Spark 4.0.0 release

[Wenchen Fan]

Hi all,

It's close to the previously proposed 4.0.0 release date (June 2024), and I
think it's time to prepare for it and discuss the ongoing projects:

   - ANSI by default
   - Spark Connect GA
   - Structured Logging
   - Streaming state store data source
   - new data type VARIANT
   - STRING collation support
   - Spark k8s operator versioning

Please help to add more items to this list that are missed here. I would
like to volunteer as the release manager for Apache Spark 4.0.0 if there is
no objection. Thank you all for the great work that fills Spark 4.0!

Wenchen Fan

Re: [DISCUSS] SPARK-44444: Use ANSI SQL mode by default

[Wenchen Fan]

+1, the existing "NULL on error" behavior is terrible for data quality.

I have one concern about error reporting with DataFrame APIs. Query
execution is lazy and where the error happens can be far away from where
the dataframe/column was created. We are improving it (PR
) but it's not fully done yet.

On Fri, Apr 12, 2024 at 2:21 PM L. C. Hsieh  wrote:

> +1
>
> I believe ANSI mode is well developed after many releases. No doubt it
> could be used.
> Since it is very easy to disable it to restore to current behavior, I
> guess the impact could be limited.
> Do we have known the possible impacts such as what are the major
> changes (e.g., what kind of queries/expressions will fail)? We can
> describe them in the release note.
>
> On Thu, Apr 11, 2024 at 10:29 PM Gengliang Wang  wrote:
> >
> >
> > +1, enabling Spark's ANSI SQL mode in version 4.0 will significantly
> enhance data quality and integrity. I fully support this initiative.
> >
> > > In other words, the current Spark ANSI SQL implementation becomes the
> first implementation for Spark SQL users to face at first while providing
> > `spark.sql.ansi.enabled=false` in the same way without losing any
> capability.`spark.sql.ansi.enabled=false` in the same way without losing
> any capability.
> >
> > BTW, the try_* functions and SQL Error Attribution Framework will also
> be beneficial in migrating to ANSI SQL mode.
> >
> >
> > Gengliang
> >
> >
> > On Thu, Apr 11, 2024 at 7:56 PM Dongjoon Hyun 
> wrote:
> >>
> >> Hi, All.
> >>
> >> Thanks to you, we've been achieving many things and have on-going SPIPs.
> >> I believe it's time to scope Apache Spark 4.0.0 (SPARK-44111) more
> narrowly
> >> by asking your opinions about Apache Spark's ANSI SQL mode.
> >>
> >> https://issues.apache.org/jira/browse/SPARK-44111
> >> Prepare Apache Spark 4.0.0
> >>
> >> SPARK-4 was proposed last year (on 15/Jul/23) as the one of
> desirable
> >> items for 4.0.0 because it's a big behavior.
> >>
> >> https://issues.apache.org/jira/browse/SPARK-4
> >> Use ANSI SQL mode by default
> >>
> >> Historically, spark.sql.ansi.enabled was added at Apache Spark 3.0.0
> and has
> >> been aiming to provide a better Spark SQL compatibility in a standard
> way.
> >> We also have a daily CI to protect the behavior too.
> >>
> >> https://github.com/apache/spark/actions/workflows/build_ansi.yml
> >>
> >> However, it's still behind the configuration with several known issues,
> e.g.,
> >>
> >> SPARK-41794 Reenable ANSI mode in test_connect_column
> >> SPARK-41547 Reenable ANSI mode in test_connect_functions
> >> SPARK-46374 Array Indexing is 1-based via ANSI SQL Standard
> >>
> >> To be clear, we know that many DBMSes have their own implementations of
> >> SQL standard and not the same. Like them, SPARK-4 aims to enable
> >> only the existing Spark's configuration, `spark.sql.ansi.enabled=true`.
> >> There is nothing more than that.
> >>
> >> In other words, the current Spark ANSI SQL implementation becomes the
> first
> >> implementation for Spark SQL users to face at first while providing
> >> `spark.sql.ansi.enabled=false` in the same way without losing any
> capability.
> >>
> >> If we don't want this change for some reasons, we can simply exclude
> >> SPARK-4 from SPARK-44111 as a part of Apache Spark 4.0.0
> preparation.
> >> It's time just to make a go/no-go decision for this item for the global
> optimization
> >> for Apache Spark 4.0.0 release. After 4.0.0, it's unlikely for us to aim
> >> for this again for the next four years until 2028.
> >>
> >> WDYT?
> >>
> >> Bests,
> >> Dongjoon
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>
>

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[Dongjoon Hyun]

+1

Thank you!

I hope we can customize `dev/merge_spark_pr.py` script per repository after 
this PR.

Dongjoon.

On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
> Hi all,
> 
> Thanks for all discussions in the thread of "Versioning of Spark
> Operator": https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
> 
> I would like to create this vote to get the consensus for versioning
> of the Spark Kubernetes Operator.
> 
> The proposal is to use an independent versioning for the Spark
> Kubernetes Operator.
> 
> Please vote on adding new `Versions` in Apache Spark JIRA which can be
> used for places like "Fix Version/s" in the JIRA tickets of the
> operator.
> 
> The new `Versions` will be `kubernetes-operator-` prefix, for example
> `kubernetes-operator-0.1.0`.
> 
> The vote is open until April 15th 1AM (PST) and passes if a majority
> +1 PMC votes are cast, with a minimum of 3 +1 votes.
> 
> [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
> Apache Spark JIRA
> [ ] -1 Do not add the new `Versions` because ...
> 
> Thank you.
> 
> 
> Note that this is not a SPIP vote and also not a release vote. I don't
> find similar votes in previous threads. This is made similarly like a
> SPIP or a release vote. So I think it should be okay. Please correct
> me if this vote format is not good for you.
> 
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
> 
> 

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[huaxin gao]

+1

On Fri, Apr 12, 2024 at 9:07 AM Dongjoon Hyun  wrote:

> +1
>
> Thank you!
>
> I hope we can customize `dev/merge_spark_pr.py` script per repository
> after this PR.
>
> Dongjoon.
>
> On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
> > Hi all,
> >
> > Thanks for all discussions in the thread of "Versioning of Spark
> > Operator":
> https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
> >
> > I would like to create this vote to get the consensus for versioning
> > of the Spark Kubernetes Operator.
> >
> > The proposal is to use an independent versioning for the Spark
> > Kubernetes Operator.
> >
> > Please vote on adding new `Versions` in Apache Spark JIRA which can be
> > used for places like "Fix Version/s" in the JIRA tickets of the
> > operator.
> >
> > The new `Versions` will be `kubernetes-operator-` prefix, for example
> > `kubernetes-operator-0.1.0`.
> >
> > The vote is open until April 15th 1AM (PST) and passes if a majority
> > +1 PMC votes are cast, with a minimum of 3 +1 votes.
> >
> > [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
> > Apache Spark JIRA
> > [ ] -1 Do not add the new `Versions` because ...
> >
> > Thank you.
> >
> >
> > Note that this is not a SPIP vote and also not a release vote. I don't
> > find similar votes in previous threads. This is made similarly like a
> > SPIP or a release vote. So I think it should be okay. Please correct
> > me if this vote format is not good for you.
> >
> > -
> > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
> >
> >
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>
>

Re: [DISCUSS] SPARK-44444: Use ANSI SQL mode by default

[huaxin gao]

+1

On Thu, Apr 11, 2024 at 11:18 PM L. C. Hsieh  wrote:

> +1
>
> I believe ANSI mode is well developed after many releases. No doubt it
> could be used.
> Since it is very easy to disable it to restore to current behavior, I
> guess the impact could be limited.
> Do we have known the possible impacts such as what are the major
> changes (e.g., what kind of queries/expressions will fail)? We can
> describe them in the release note.
>
> On Thu, Apr 11, 2024 at 10:29 PM Gengliang Wang  wrote:
> >
> >
> > +1, enabling Spark's ANSI SQL mode in version 4.0 will significantly
> enhance data quality and integrity. I fully support this initiative.
> >
> > > In other words, the current Spark ANSI SQL implementation becomes the
> first implementation for Spark SQL users to face at first while providing
> > `spark.sql.ansi.enabled=false` in the same way without losing any
> capability.`spark.sql.ansi.enabled=false` in the same way without losing
> any capability.
> >
> > BTW, the try_* functions and SQL Error Attribution Framework will also
> be beneficial in migrating to ANSI SQL mode.
> >
> >
> > Gengliang
> >
> >
> > On Thu, Apr 11, 2024 at 7:56 PM Dongjoon Hyun 
> wrote:
> >>
> >> Hi, All.
> >>
> >> Thanks to you, we've been achieving many things and have on-going SPIPs.
> >> I believe it's time to scope Apache Spark 4.0.0 (SPARK-44111) more
> narrowly
> >> by asking your opinions about Apache Spark's ANSI SQL mode.
> >>
> >> https://issues.apache.org/jira/browse/SPARK-44111
> >> Prepare Apache Spark 4.0.0
> >>
> >> SPARK-4 was proposed last year (on 15/Jul/23) as the one of
> desirable
> >> items for 4.0.0 because it's a big behavior.
> >>
> >> https://issues.apache.org/jira/browse/SPARK-4
> >> Use ANSI SQL mode by default
> >>
> >> Historically, spark.sql.ansi.enabled was added at Apache Spark 3.0.0
> and has
> >> been aiming to provide a better Spark SQL compatibility in a standard
> way.
> >> We also have a daily CI to protect the behavior too.
> >>
> >> https://github.com/apache/spark/actions/workflows/build_ansi.yml
> >>
> >> However, it's still behind the configuration with several known issues,
> e.g.,
> >>
> >> SPARK-41794 Reenable ANSI mode in test_connect_column
> >> SPARK-41547 Reenable ANSI mode in test_connect_functions
> >> SPARK-46374 Array Indexing is 1-based via ANSI SQL Standard
> >>
> >> To be clear, we know that many DBMSes have their own implementations of
> >> SQL standard and not the same. Like them, SPARK-4 aims to enable
> >> only the existing Spark's configuration, `spark.sql.ansi.enabled=true`.
> >> There is nothing more than that.
> >>
> >> In other words, the current Spark ANSI SQL implementation becomes the
> first
> >> implementation for Spark SQL users to face at first while providing
> >> `spark.sql.ansi.enabled=false` in the same way without losing any
> capability.
> >>
> >> If we don't want this change for some reasons, we can simply exclude
> >> SPARK-4 from SPARK-44111 as a part of Apache Spark 4.0.0
> preparation.
> >> It's time just to make a go/no-go decision for this item for the global
> optimization
> >> for Apache Spark 4.0.0 release. After 4.0.0, it's unlikely for us to aim
> >> for this again for the next four years until 2028.
> >>
> >> WDYT?
> >>
> >> Bests,
> >> Dongjoon
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>
>

Re: [DISCUSS] SPARK-44444: Use ANSI SQL mode by default

[serge rielau . com]

+1 it‘s the wrapping on math overflows that does it for me.

Sent from my iPhone

On Apr 12, 2024, at 9:36 AM, huaxin gao  wrote:


+1

On Thu, Apr 11, 2024 at 11:18 PM L. C. Hsieh 
mailto:vii...@gmail.com>> wrote:
+1

I believe ANSI mode is well developed after many releases. No doubt it
could be used.
Since it is very easy to disable it to restore to current behavior, I
guess the impact could be limited.
Do we have known the possible impacts such as what are the major
changes (e.g., what kind of queries/expressions will fail)? We can
describe them in the release note.

On Thu, Apr 11, 2024 at 10:29 PM Gengliang Wang 
mailto:ltn...@gmail.com>> wrote:
>
>
> +1, enabling Spark's ANSI SQL mode in version 4.0 will significantly enhance 
> data quality and integrity. I fully support this initiative.
>
> > In other words, the current Spark ANSI SQL implementation becomes the first 
> > implementation for Spark SQL users to face at first while providing
> `spark.sql.ansi.enabled=false` in the same way without losing any 
> capability.`spark.sql.ansi.enabled=false` in the same way without losing any 
> capability.
>
> BTW, the try_* functions and SQL Error Attribution Framework will also be 
> beneficial in migrating to ANSI SQL mode.
>
>
> Gengliang
>
>
> On Thu, Apr 11, 2024 at 7:56 PM Dongjoon Hyun 
> mailto:dongjoon.h...@gmail.com>> wrote:
>>
>> Hi, All.
>>
>> Thanks to you, we've been achieving many things and have on-going SPIPs.
>> I believe it's time to scope Apache Spark 4.0.0 (SPARK-44111) more narrowly
>> by asking your opinions about Apache Spark's ANSI SQL mode.
>>
>> https://issues.apache.org/jira/browse/SPARK-44111
>> Prepare Apache Spark 4.0.0
>>
>> SPARK-4 was proposed last year (on 15/Jul/23) as the one of desirable
>> items for 4.0.0 because it's a big behavior.
>>
>> https://issues.apache.org/jira/browse/SPARK-4
>> Use ANSI SQL mode by default
>>
>> Historically, spark.sql.ansi.enabled was added at Apache Spark 3.0.0 and has
>> been aiming to provide a better Spark SQL compatibility in a standard way.
>> We also have a daily CI to protect the behavior too.
>>
>> https://github.com/apache/spark/actions/workflows/build_ansi.yml
>>
>> However, it's still behind the configuration with several known issues, e.g.,
>>
>> SPARK-41794 Reenable ANSI mode in test_connect_column
>> SPARK-41547 Reenable ANSI mode in test_connect_functions
>> SPARK-46374 Array Indexing is 1-based via ANSI SQL Standard
>>
>> To be clear, we know that many DBMSes have their own implementations of
>> SQL standard and not the same. Like them, SPARK-4 aims to enable
>> only the existing Spark's configuration, `spark.sql.ansi.enabled=true`.
>> There is nothing more than that.
>>
>> In other words, the current Spark ANSI SQL implementation becomes the first
>> implementation for Spark SQL users to face at first while providing
>> `spark.sql.ansi.enabled=false` in the same way without losing any capability.
>>
>> If we don't want this change for some reasons, we can simply exclude
>> SPARK-4 from SPARK-44111 as a part of Apache Spark 4.0.0 preparation.
>> It's time just to make a go/no-go decision for this item for the global 
>> optimization
>> for Apache Spark 4.0.0 release. After 4.0.0, it's unlikely for us to aim
>> for this again for the next four years until 2028.
>>
>> WDYT?
>>
>> Bests,
>> Dongjoon

-
To unsubscribe e-mail: 
dev-unsubscr...@spark.apache.org

Re: [DISCUSS] Spark 4.0.0 release

[Dongjoon Hyun]

Thank you for volunteering, Wenchen.

Dongjoon.

On 2024/04/12 15:11:04 Wenchen Fan wrote:
> Hi all,
> 
> It's close to the previously proposed 4.0.0 release date (June 2024), and I
> think it's time to prepare for it and discuss the ongoing projects:
> 
>- ANSI by default
>- Spark Connect GA
>- Structured Logging
>- Streaming state store data source
>- new data type VARIANT
>- STRING collation support
>- Spark k8s operator versioning
> 
> Please help to add more items to this list that are missed here. I would
> like to volunteer as the release manager for Apache Spark 4.0.0 if there is
> no objection. Thank you all for the great work that fills Spark 4.0!
> 
> Wenchen Fan
> 

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: [DISCUSS] SPARK-44444: Use ANSI SQL mode by default

[Nicholas Chammas]

This is a side issue, but I’d like to bring people’s attention to SPARK-28024. 

Cases 2, 3, and 4 described in that ticket are still problems today on master 
(I just rechecked) even with ANSI mode enabled.

Well, maybe not problems, but I’m flagging this since Spark’s behavior differs 
in these cases from Postgres, as described in the ticket.


> On Apr 12, 2024, at 12:09 AM, Gengliang Wang  wrote:
> 
> 
> +1, enabling Spark's ANSI SQL mode in version 4.0 will significantly enhance 
> data quality and integrity. I fully support this initiative.
> 
> > In other words, the current Spark ANSI SQL implementation becomes the first 
> > implementation for Spark SQL users to face at first while providing
> `spark.sql.ansi.enabled=false` in the same way without losing any 
> capability.`spark.sql.ansi.enabled=false` in the same way without losing any 
> capability.
> 
> BTW, the try_* 
> 
>  functions and SQL Error Attribution Framework 
>  will also be beneficial 
> in migrating to ANSI SQL mode.
> 
> 
> Gengliang
> 
> 
> On Thu, Apr 11, 2024 at 7:56 PM Dongjoon Hyun  > wrote:
>> Hi, All.
>> 
>> Thanks to you, we've been achieving many things and have on-going SPIPs.
>> I believe it's time to scope Apache Spark 4.0.0 (SPARK-44111) more narrowly
>> by asking your opinions about Apache Spark's ANSI SQL mode.
>> 
>> https://issues.apache.org/jira/browse/SPARK-44111
>> Prepare Apache Spark 4.0.0
>> 
>> SPARK-4 was proposed last year (on 15/Jul/23) as the one of desirable
>> items for 4.0.0 because it's a big behavior.
>> 
>> https://issues.apache.org/jira/browse/SPARK-4
>> Use ANSI SQL mode by default
>> 
>> Historically, spark.sql.ansi.enabled was added at Apache Spark 3.0.0 and has
>> been aiming to provide a better Spark SQL compatibility in a standard way.
>> We also have a daily CI to protect the behavior too.
>> 
>> https://github.com/apache/spark/actions/workflows/build_ansi.yml
>> 
>> However, it's still behind the configuration with several known issues, e.g.,
>> 
>> SPARK-41794 Reenable ANSI mode in test_connect_column
>> SPARK-41547 Reenable ANSI mode in test_connect_functions
>> SPARK-46374 Array Indexing is 1-based via ANSI SQL Standard
>> 
>> To be clear, we know that many DBMSes have their own implementations of
>> SQL standard and not the same. Like them, SPARK-4 aims to enable
>> only the existing Spark's configuration, `spark.sql.ansi.enabled=true`.
>> There is nothing more than that.
>> 
>> In other words, the current Spark ANSI SQL implementation becomes the first
>> implementation for Spark SQL users to face at first while providing
>> `spark.sql.ansi.enabled=false` in the same way without losing any capability.
>> 
>> If we don't want this change for some reasons, we can simply exclude
>> SPARK-4 from SPARK-44111 as a part of Apache Spark 4.0.0 preparation.
>> It's time just to make a go/no-go decision for this item for the global 
>> optimization
>> for Apache Spark 4.0.0 release. After 4.0.0, it's unlikely for us to aim
>> for this again for the next four years until 2028.
>> 
>> WDYT?
>> 
>> Bests,
>> Dongjoon

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[L. C. Hsieh]

+1

Thank you, Dongjoon. Yea, We may need to customize the merge script
for a particular repository.


On Fri, Apr 12, 2024 at 9:07 AM Dongjoon Hyun  wrote:
>
> +1
>
> Thank you!
>
> I hope we can customize `dev/merge_spark_pr.py` script per repository after 
> this PR.
>
> Dongjoon.
>
> On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
> > Hi all,
> >
> > Thanks for all discussions in the thread of "Versioning of Spark
> > Operator": https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
> >
> > I would like to create this vote to get the consensus for versioning
> > of the Spark Kubernetes Operator.
> >
> > The proposal is to use an independent versioning for the Spark
> > Kubernetes Operator.
> >
> > Please vote on adding new `Versions` in Apache Spark JIRA which can be
> > used for places like "Fix Version/s" in the JIRA tickets of the
> > operator.
> >
> > The new `Versions` will be `kubernetes-operator-` prefix, for example
> > `kubernetes-operator-0.1.0`.
> >
> > The vote is open until April 15th 1AM (PST) and passes if a majority
> > +1 PMC votes are cast, with a minimum of 3 +1 votes.
> >
> > [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
> > Apache Spark JIRA
> > [ ] -1 Do not add the new `Versions` because ...
> >
> > Thank you.
> >
> >
> > Note that this is not a SPIP vote and also not a release vote. I don't
> > find similar votes in previous threads. This is made similarly like a
> > SPIP or a release vote. So I think it should be okay. Please correct
> > me if this vote format is not good for you.
> >
> > -
> > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
> >
> >
>
> -
> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>

-
To unsubscribe e-mail: dev-unsubscr...@spark.apache.org

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[bo yang]

+1

On Fri, Apr 12, 2024 at 12:34 PM huaxin gao  wrote:

> +1
>
> On Fri, Apr 12, 2024 at 9:07 AM Dongjoon Hyun  wrote:
>
>> +1
>>
>> Thank you!
>>
>> I hope we can customize `dev/merge_spark_pr.py` script per repository
>> after this PR.
>>
>> Dongjoon.
>>
>> On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
>> > Hi all,
>> >
>> > Thanks for all discussions in the thread of "Versioning of Spark
>> > Operator":
>> https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
>> >
>> > I would like to create this vote to get the consensus for versioning
>> > of the Spark Kubernetes Operator.
>> >
>> > The proposal is to use an independent versioning for the Spark
>> > Kubernetes Operator.
>> >
>> > Please vote on adding new `Versions` in Apache Spark JIRA which can be
>> > used for places like "Fix Version/s" in the JIRA tickets of the
>> > operator.
>> >
>> > The new `Versions` will be `kubernetes-operator-` prefix, for example
>> > `kubernetes-operator-0.1.0`.
>> >
>> > The vote is open until April 15th 1AM (PST) and passes if a majority
>> > +1 PMC votes are cast, with a minimum of 3 +1 votes.
>> >
>> > [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
>> > Apache Spark JIRA
>> > [ ] -1 Do not add the new `Versions` because ...
>> >
>> > Thank you.
>> >
>> >
>> > Note that this is not a SPIP vote and also not a release vote. I don't
>> > find similar votes in previous threads. This is made similarly like a
>> > SPIP or a release vote. So I think it should be okay. Please correct
>> > me if this vote format is not good for you.
>> >
>> > -
>> > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>> >
>> >
>>
>> -
>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>>
>>

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[Xiao Li]

+1




On Fri, Apr 12, 2024 at 14:30 bo yang  wrote:

> +1
>
> On Fri, Apr 12, 2024 at 12:34 PM huaxin gao 
> wrote:
>
>> +1
>>
>> On Fri, Apr 12, 2024 at 9:07 AM Dongjoon Hyun 
>> wrote:
>>
>>> +1
>>>
>>> Thank you!
>>>
>>> I hope we can customize `dev/merge_spark_pr.py` script per repository
>>> after this PR.
>>>
>>> Dongjoon.
>>>
>>> On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
>>> > Hi all,
>>> >
>>> > Thanks for all discussions in the thread of "Versioning of Spark
>>> > Operator":
>>> https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
>>> >
>>> > I would like to create this vote to get the consensus for versioning
>>> > of the Spark Kubernetes Operator.
>>> >
>>> > The proposal is to use an independent versioning for the Spark
>>> > Kubernetes Operator.
>>> >
>>> > Please vote on adding new `Versions` in Apache Spark JIRA which can be
>>> > used for places like "Fix Version/s" in the JIRA tickets of the
>>> > operator.
>>> >
>>> > The new `Versions` will be `kubernetes-operator-` prefix, for example
>>> > `kubernetes-operator-0.1.0`.
>>> >
>>> > The vote is open until April 15th 1AM (PST) and passes if a majority
>>> > +1 PMC votes are cast, with a minimum of 3 +1 votes.
>>> >
>>> > [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
>>> > Apache Spark JIRA
>>> > [ ] -1 Do not add the new `Versions` because ...
>>> >
>>> > Thank you.
>>> >
>>> >
>>> > Note that this is not a SPIP vote and also not a release vote. I don't
>>> > find similar votes in previous threads. This is made similarly like a
>>> > SPIP or a release vote. So I think it should be okay. Please correct
>>> > me if this vote format is not good for you.
>>> >
>>> > -
>>> > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>>> >
>>> >
>>>
>>> -
>>> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
>>>
>>>

Re: [VOTE] Add new `Versions` in Apache Spark JIRA for Versioning of Spark Operator

[Chao Sun]

+1

On Fri, Apr 12, 2024 at 4:23 PM Xiao Li 
wrote:

> +1
>
>
>
>
> On Fri, Apr 12, 2024 at 14:30 bo yang  wrote:
>
>> +1
>>
>
>> On Fri, Apr 12, 2024 at 12:34 PM huaxin gao 
>> wrote:
>>
>>> +1
>>>
>>> On Fri, Apr 12, 2024 at 9:07 AM Dongjoon Hyun 
>>> wrote:
>>>
 +1

 Thank you!

 I hope we can customize `dev/merge_spark_pr.py` script per repository
 after this PR.

 Dongjoon.

 On 2024/04/12 03:28:36 "L. C. Hsieh" wrote:
 > Hi all,
 >
 > Thanks for all discussions in the thread of "Versioning of Spark
 > Operator":
 https://lists.apache.org/thread/zhc7nb2sxm8jjxdppq8qjcmlf4rcsthh
 >
 > I would like to create this vote to get the consensus for versioning
 > of the Spark Kubernetes Operator.
 >
 > The proposal is to use an independent versioning for the Spark
 > Kubernetes Operator.
 >
 > Please vote on adding new `Versions` in Apache Spark JIRA which can be
 > used for places like "Fix Version/s" in the JIRA tickets of the
 > operator.
 >
 > The new `Versions` will be `kubernetes-operator-` prefix, for example
 > `kubernetes-operator-0.1.0`.
 >
 > The vote is open until April 15th 1AM (PST) and passes if a majority
 > +1 PMC votes are cast, with a minimum of 3 +1 votes.
 >
 > [ ] +1 Adding the new `Versions` for Spark Kubernetes Operator in
 > Apache Spark JIRA
 > [ ] -1 Do not add the new `Versions` because ...
 >
 > Thank you.
 >
 >
 > Note that this is not a SPIP vote and also not a release vote. I don't
 > find similar votes in previous threads. This is made similarly like a
 > SPIP or a release vote. So I think it should be okay. Please correct
 > me if this vote format is not good for you.
 >
 > -
 > To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
 >
 >

 -
 To unsubscribe e-mail: dev-unsubscr...@spark.apache.org