flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tzu-Li (Gordon) Tai" <tzuli...@apache.org>
Subject Re: [VOTE] Release Apache Flink 1.3.1
Date Mon, 19 Jun 2017 12:20:42 GMT
I looked at the changes in the PRs [1, 2].
I agree that it would be better to include the fixes in 1.3.1.

If we agree to cancel RC1 for RC2 (with shorter voting period), I’ll start massaging the
PRs to be merged for 1.3.1 (currently the changes in the PRs are targeted for 1.3.2).
They should be ready before tomorrow, so that we can start RC2 soon.


On 19 June 2017 at 8:06:11 PM, Robert Metzger (rmetzger@apache.org) wrote:

If we really have to introduce a special path in the serializer config for  
1.3.1 to 1.3.2, then I would indeed suggest to cancel the RC1.  

If only this one commit is different between RC1 and RC2, we can do a  
reduced voting period for RC2.  

On Mon, Jun 19, 2017 at 2:02 PM, Till Rohrmann <trohrmann@apache.org> wrote:  

> I think this actually not true, since in 1.3.0 the field `enumConstants` in  
> `ScalaEnumSerializerConfigSnapshot` was always serialized as `null`. Thus,  
> due to this we wouldn't have to bump the format if we included FLINK-6948  
> in 1.3.1. If this weren't the case, we would have to bump it also for 1.3.1  
> (excluding FLINK-6948).  
>  
> Cheers,  
> Till  
>  
> On Mon, Jun 19, 2017 at 1:39 PM, Tzu-Li (Gordon) Tai <tzulitai@apache.org>  
> wrote:  
>  
> > No, I meant that if we include FLINK-6921 / FLINK-6948 in 1.3.1, we also  
> > still need to bump the version due to changes in FLINK-6948.  
> > So, that the version needs to be bumped would not be a reason to block  
> > 1.3.1 on it, because we have to do it either way.  
> >  
> > On 19 June 2017 at 7:33:25 PM, Till Rohrmann (trohrmann@apache.org)  
> wrote:  
> >  
> > Do you mean that we have to bump the version also without including  
> > FLINK-6921 and FLINK-6948? Wouldn't that be a release blocker then?  
> >  
> > I think that we actually introduced FLINK-6921 with [1]. Thus, the  
> > `ArrayIndexOutOfBoundsException` is specific to this release. However, I  
> > agree that the serializer was broken before as well, however, in a  
> > different way.  
> >  
> > [1]  
> > https://github.com/apache/flink/commit/5281dd6598f17c8dfe0c7b091c90c8  
> > 721d305375  
> >  
> > Cheers,  
> > Till  
> >  
> > On Mon, Jun 19, 2017 at 1:22 PM, Tzu-Li (Gordon) Tai <  
> tzulitai@apache.org>  
> > wrote:  
> >  
> > > The ScalaEnumSerializerConfigSnapshot would need a version bump  
> > > regardless of whether or not the fixes are included in 1.3.1.  
> > > In other words, we still need to bump the version if we include it for  
> > > 1.3.1.  
> > >  
> > > I’m not against including FLINK-6921 and FLINK-6948 in for 1.3.1, but  
> > then  
> > > as usual the argument would be that the problem had always been there  
> and  
> > > is not specific to this release.  
> > > I’m personally usually favorable of delaying the release a bit more to  
> > get  
> > > fixes for issues we know of in.  
> > >  
> > > I’ll look at the PRs for FLINK-6921 and FLINK-6948 now, and merge them  
> > > soon. We could probably have a RC2 with a shorter vote duration?  
> > >  
> > > Best,  
> > > Gordon  
> > >  
> > > On 19 June 2017 at 7:10:11 PM, Till Rohrmann (trohrmann@apache.org)  
> > wrote:  
> > >  
> > > I think the EnumValueSerializer [1, 2] is broken in the current RC.  
> This  
> > > basically means that Flink programs won’t properly notice that state  
> > > migration is required and or fail with obscure exceptions at migration  
> > > check or runtime.  
> > >  
> > > This definitely will be enough reason for another bug fix release if we  
> > > don’t want to include fixes in 1.3.1. If we include the fixes in 1.3.2, 

> > > then this will require a version bump for the  
> > > ScalaEnumSerializerConfigSnapshot because we have to change the  
> format.  
> > > This also entails code for backwards compatibility.  
> > >  
> > > [1] https://issues.apache.org/jira/browse/FLINK-6921  
> > > [2] https://issues.apache.org/jira/browse/FLINK-6948  
> > >  
> > > Cheers,  
> > > Till  
> > > ​  
> > >  
> > > On Mon, Jun 19, 2017 at 10:34 AM, Dawid Wysakowicz <  
> > > wysakowicz.dawid@gmail.com> wrote:  
> > >  
> > > > +1  
> > > >  
> > > > - built from source (2.10, 2.11)  
> > > > - checked aggregate function with AggregateFunction return type  
> > different  
> > > > than stream type  
> > > >  
> > > > Z pozdrowieniami! / Cheers!  
> > > >  
> > > > Dawid Wysakowicz  
> > > >  
> > > > *Data/Software Engineer*  
> > > >  
> > > > Skype: dawid_wys | Twitter: @OneMoreCoder  
> > > >  
> > > > <http://getindata.com/>  
> > > >  
> > > > 2017-06-19 7:15 GMT+02:00 Tzu-Li (Gordon) Tai <tzulitai@apache.org>:
 
> > > >  
> > > > > +1  
> > > > >  
> > > > > Tested the following blockers of 1.3.1:  
> > > > >  
> > > > > Serializers & checkpointing  
> > > > > - Verified Scala jobs using Scala types as state (Scala  
> collections,  
> > > case  
> > > > > classes, Either, Try, etc.) can restore from savepoints taken with
 
> > > Flink  
> > > > > 1.2.1 & 1.3.1. Tested with Scala 2.10 & 2.11.  
> > > > > - Tested restore of POJO types as state, behavior & error messages
 
> > for  
> > > > > changed POJO types consistent across different state backends  
> > > > > - Tested stream join with checkpointing enabled  
> > > > > - Sharing static state descriptor (w/ stateful KryoSerializer)  
> across  
> > > > > tasks did not reveal any issues  
> > > > >  
> > > > > Elasticsearch connector  
> > > > > - ES 5 connector artifacts exists in staging repo  
> > > > > - Tested cluster execution with ES sink (2.3.5, 2.4.1, 5.1.2), no
 
> > > > > dependency conflicts, successful  
> > > > >  
> > > > > Flink CEP  
> > > > > - Out-of-order matched events is now resolved  
> > > > >  
> > > > > - Ran local build + test on MacOS (-Dscala-2.10, -Dscala-2.11), 

> > > > successful  
> > > > > - LICENSES untouched since 1.3.0  
> > > > > - No new dependencies  
> > > > >  
> > > > > Best,  
> > > > > Gordon  
> > > > >  
> > > > > On 14 June 2017 at 10:14:39 PM, Robert Metzger (  
> rmetzger@apache.org)  
> > > > > wrote:  
> > > > >  
> > > > > Dear Flink community,  
> > > > >  
> > > > > Please vote on releasing the following candidate as Apache Flink
 
> > > version  
> > > > > 1.3.1.  
> > > > >  
> > > > > The commit to be voted on:  
> > > > > http://git-wip-us.apache.org/repos/asf/flink/commit/7cfe62b9  
> > > > >  
> > > > > Branch:  
> > > > > release-1.3.1-rc1  
> > > > >  
> > > > > The release artifacts to be voted on can be found at:  
> > > > > *http://people.apache.org/~rmetzger/flink-1.3.1-rc1/  
> > > > > <http://people.apache.org/~rmetzger/flink-1.3.1-rc1/>*  
> > > > >  
> > > > > The release artifacts are signed with the key with fingerprint  
> > > D9839159:  
> > > > > http://www.apache.org/dist/flink/KEYS  
> > > > >  
> > > > > The staging repository for this release can be found at:  
> > > > > https://repository.apache.org/content/repositories/  
> > orgapacheflink-1124  
> > > > >  
> > > > >  
> > > > > -------------------------------------------------------------  
> > > > >  
> > > > >  
> > > > > The vote ends on Monday (5pm CEST), June 19rd, 2016.  
> > > > >  
> > > > > [ ] +1 Release this package as Apache Flink 1.3.1  
> > > > > [ ] -1 Do not release this package, because ...  
> > > > >  
> > > >  
> > >  
> >  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message