Canceling the vote.

Thanks Karin for giving 1.9.0 RC a try. I'll release RC4 soon with your
patch.

Cheers, Fokko

Op vr 3 mei 2019 om 12:33 schreef Nandor Kollar
<[email protected]>:

> Okay, I created a Jira: https://issues.apache.org/jira/browse/AVRO-2386
>
> Thanks Katrin, nice catch! You can open a PR for
> https://github.com/apache/avro.
>
> Because this is a regression, I vote -1 (non-binding) on RC3
>
> On Fri, May 3, 2019 at 12:20 PM Katrin Skoglund <[email protected]
> >
> wrote:
>
> > I realized I don't have a Jira account, should I sign up for one?
> >
> > On 2019-05-03, 12:09, "Nandor Kollar" <[email protected]>
> > wrote:
> >
> >     Ah, okay, I see. Well, in this case it is a release blocker then,
> > since it
> >     is indeed a regression. If you've an account to Apache Jira, please
> > file a
> >     Jira here: https://issues.apache.org/jira/projects/AVRO/issues
> >
> >     On Fri, May 3, 2019 at 11:38 AM Katrin Skoglund <
> > [email protected]>
> >     wrote:
> >
> >     > Hi Nandor!
> >     >
> >     > Ah, I wasn't aware that the method is new. What I actually meant
> was
> > that
> >     > code generation that previously worked now generates code that no
> > longer
> >     > compiles, which I would say is a regression. The implementation of
> >     > customEncode() in the class representing the outer record calls the
> >     > corresponding method on its nested records, which won't compile if
> > they are
> >     > in different packages. This did not happen before since the method
> > did not
> >     > exist, so the code compiled. Here's an example schema that
> > reproduces the
> >     > problem:
> >     >
> >     > {"namespace": "org.apache.avro.codegentest.some",
> >     >   "type": "record",
> >     >   "name": "NestedSomeNamespaceRecord",
> >     >   "doc" : "Test nested types with different namespace than the
> outer
> > type",
> >     >   "fields": [
> >     >     {
> >     >       "name": "nestedRecord",
> >     >       "type": {
> >     >         "namespace": "org.apache.avro.codegentest.other",
> >     >         "type": "record",
> >     >         "name": "NestedOtherNamespaceRecord",
> >     >         "fields": [
> >     >           {
> >     >             "name": "someField",
> >     >             "type": "int"
> >     >           }
> >     >         ]
> >     >       }
> >     >     }]
> >     > }
> >     >
> >     > And an example from the generated code:
> >     >
> >     >   @Override protected void customEncode(org.apache.avro.io.Encoder
> > out)
> >     >     throws java.io.IOException
> >     >   {
> >     >     this.nestedRecord.customEncode(out);
> >     >
> >     >   }
> >     >
> >     > //Katrin
> >     >
> >     >
> >     > On 2019-05-03, 11:15, "Nandor Kollar" <[email protected]
> >
> >     > wrote:
> >     >
> >     >     Hi Katrin,
> >     >
> >     >     It appears to me, that these methods didn't exist in previous
> > Avro
> >     >     versions, they were added in
> > https://github.com/apache/avro/pull/350
> >     > and
> >     >     were renamed and reduced their visibility in
> >     >
> >     >
> >
> https://github.com/apache/avro/pull/350/commits/d320b6b536c49b485be45286dbdb73226eef4b35
> >     > .
> >     >     Actually it looks like the version with public visibility
> wasn't
> > even
> >     >     merged to master.
> >     >
> >     >     Are you using a fork of Avro where these method were public, or
> > am I
> >     >     missing something? I'm not against of making these methods
> public
> >     > (however
> >     >     I guess the author of the change had some reason to reduce the
> > scope
> >     > form
> >     >     public to protected), however don't think this should be a
> > blocker for
> >     > the
> >     >     release, as this doesn't seem to be a regression.
> >     >
> >     >     Thanks,
> >     >     Nandor
> >     >
> >     >     On Fri, May 3, 2019 at 10:43 AM Katrin Skoglund <
> >     > [email protected]>
> >     >     wrote:
> >     >
> >     >     > Hi all,
> >     >     >
> >     >     > I just managed to test the new RC, specifically the Java code
> >     > generation,
> >     >     > with one of the libraries we use. I then noticed that their
> >     > generated java
> >     >     > code no longer compiles because of a change in access level
> of
> > two
> >     > methods.
> >     >     >
> >     >     > The generated methods customEncode and customDecode are
> > protected in
> >     > this
> >     >     > version of Avro. They used to be public. This means that the
> >     > generated java
> >     >     > code for schemas using nested records with different
> > namespaces will
> >     > no
> >     >     > longer compile.
> >     >     >
> >     >     > I think it would be good to fix this before releasing since
> it
> > is a
> >     > real
> >     >     > easy fix, unless there is a good reason why the access level
> > was
> >     > changed to
> >     >     > protected?
> >     >     >
> >     >     > I'll start a PR for this anyway, please let me know if you
> > want the
> >     > fix in
> >     >     > some other way or if I should create a Jira first (new to the
> > process
> >     >     > here).
> >     >     >
> >     >     > //Katrin
> >     >     >
> >     >     >
> >     >     > On 2019-04-30, 12:55, "Driesprong, Fokko"
> <[email protected]
> > >
> >     > wrote:
> >     >     >
> >     >     >     Hi everyone,
> >     >     >
> >     >     >     Since the last release of Apache Avro 1.8.2 on May 31,
> > 2017. Two
> >     > years
> >     >     >     later,
> >     >     >     I'm thrilled to propose the following RC to be released
> as
> >     > official
> >     >     > Apache
> >     >     >     Avro 1.9.0 release.
> >     >     >
> >     >     >     The commit id is 24ff48c32d8d13433a1e31e485ef2af187d1eb62
> >     >     >     * This corresponds to the tag: release-1.9.0-rc3
> >     >     >     *
> > https://github.com/apache/avro/releases/tag/release-1.9.0-rc3/
> >     >     >
> >     >     >     The release tarball, signature, and checksums are here:
> >     >     >     *
> > https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc3/
> >     >     >
> >     >     >     You can find the KEYS file here:
> >     >     >     * https://dist.apache.org/repos/dist/dev/avro/KEYS
> >     >     >
> >     >     >     Binary artifacts for Java are staged in Nexus here:
> >     >     >     *
> >     >     >
> >     >     >
> >     >
> >
> https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
> >     >     >
> >     >     >     This release includes 272 Jira issues:
> >     >     >
> > https://issues.apache.org/jira/projects/AVRO/versions/12333394
> >     >     >     * Deprecate Joda-Time in favor of Java8 JSR310 and
> setting
> > it as
> >     >     > default
> >     >     >     * Remove support for Hadoop 1.x
> >     >     >     * Move from Jackson 1.x to 2.9
> >     >     >     * Add ZStandard Codec
> >     >     >     * Lots of updates on the dependencies to fix CVE's
> >     >     >     * and many, many more!
> >     >     >
> >     >     >     Since RC1, two commits have been added:
> >     >     >     * https://jira.apache.org/jira/browse/AVRO-2381
> >     >     >     * https://jira.apache.org/jira/browse/AVRO-2383
> >     >     >
> >     >     >     Since RC2 the SHA1/MD5 checksums have been replaced with
> > SHA512
> >     >     >
> >     >     >     Please download, verify, and test. This vote will remain
> > open
> >     > for at
> >     >     > least
> >     >     >     72 hours. Given sufficient votes, I would like to close
> it
> > on or
> >     > about
> >     >     >     midnight
> >     >     >     on Saturday, 4th of May 2019.
> >     >     >
> >     >     >     [ ] +1 Release this as Apache Avro 1.9.0
> >     >     >     [ ] +0
> >     >     >     [ ] -1 Do not release this because...
> >     >     >
> >     >     >     Consider this a +1 (non-binding) from my side:
> >     >     >     * Compiled the new version of Parquet against the Divolte
> >     > collector and
> >     >     >     Apache Parquet
> >     >     >
> >     >     >     Cheers, Fokko Driesprong
> >     >     >
> >     >     >
> >     >     >
> >     >
> >     >
> >     >
> >
> >
> >
>

Reply via email to