Return-Path: X-Original-To: apmail-flink-dev-archive@www.apache.org Delivered-To: apmail-flink-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F07CB1797B for ; Thu, 18 Jun 2015 09:01:00 +0000 (UTC) Received: (qmail 71035 invoked by uid 500); 18 Jun 2015 09:01:00 -0000 Delivered-To: apmail-flink-dev-archive@flink.apache.org Received: (qmail 70981 invoked by uid 500); 18 Jun 2015 09:01:00 -0000 Mailing-List: contact dev-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list dev@flink.apache.org Received: (qmail 70970 invoked by uid 99); 18 Jun 2015 09:01:00 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Jun 2015 09:01:00 +0000 Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 899CC1A0046 for ; Thu, 18 Jun 2015 09:01:00 +0000 (UTC) Received: by ykfl8 with SMTP id l8so61020724ykf.1 for ; Thu, 18 Jun 2015 02:00:59 -0700 (PDT) X-Gm-Message-State: ALoCoQkeMAQLcqHLQA0admnAf3+tUoH9St587DBnTU9XBHRS5ukewnsnkJlzu6J4uOwF1XgsLYEP X-Received: by 10.52.142.49 with SMTP id rt17mr7877426vdb.50.1434618059516; Thu, 18 Jun 2015 02:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.207.67 with HTTP; Thu, 18 Jun 2015 02:00:39 -0700 (PDT) From: Maximilian Michels Date: Thu, 18 Jun 2015 11:00:39 +0200 Message-ID: Subject: [VOTE] [CANCELLED] Release Apache Flink 0.9.0 (release-0.9.0-rc3) To: dev@flink.apache.org Content-Type: multipart/alternative; boundary=bcaec51b9b63d3874f0518c70b2b --bcaec51b9b63d3874f0518c70b2b Content-Type: text/plain; charset=UTF-8 Due to concerns raised about the quality of the release candidate, I cancel the vote for "release-0.9.0-rc3". On Thu, Jun 18, 2015 at 10:24 AM, Till Rohrmann wrote: > +1 for reverting. > > On Thu, Jun 18, 2015 at 10:11 AM Aljoscha Krettek > wrote: > > > +1 I also think it's the cleanest solution for now. The table API still > > works, just without support for null values. > > > > On Thu, 18 Jun 2015 at 10:08 Maximilian Michels wrote: > > > > > I also vote for reverting the Table API changes. > > > > > > On Wed, Jun 17, 2015 at 6:16 PM, Ufuk Celebi wrote: > > > > > > > > > > > On 17 Jun 2015, at 18:05, Aljoscha Krettek > > wrote: > > > > > > > > > -1 > > > > > > > > > > There is a bug in the newly introduced Null-Value support in > > > > RowSerializer: > > > > > The serializer was changed to write booleans that signify if a > field > > is > > > > > null. For comparison this still uses the TupleComparatorBase (via > > > > > CaseClassComparator) which is not aware of these changes. > > > > > > > > > > The reason why no Unit-Test found this problem is that it only > occurs > > > if > > > > > very long keys are used that exceed the normalised-key length. Only > > > then > > > > do > > > > > we actually have to compare the binary data. > > > > > > > > > > I see three options: > > > > > - Revert the relevant Table API changes > > > > > - Create a new RowComparator that does not derive from > > > > CaseClassComparator > > > > > but basically copies almost all the code > > > > > - Add support for null-values in Tuples and Case classes as well, > > > thereby > > > > > bringing all composite types in sync regarding null-values. > > > > > > > > I vote vor option 1 for now. > > > > > > > > > > --bcaec51b9b63d3874f0518c70b2b--