Re: [VOTE] Release Apache Avro 1.9.0 RC3
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
:
> 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 >
> wrote:
>
> > I realized I don't have a Jira account, should I sign up for one?
> >
> > On 2019-05-03, 12:09, "Nandor Kollar"
> > 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 <
> > katrin.skogl...@avanza.se>
> > 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" >
> > > 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 <
> > > katrin.skogl...@avanza.se>
> > > 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
> >
Re: [VOTE] Release Apache Avro 1.9.0 RC3
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
wrote:
> I realized I don't have a Jira account, should I sign up for one?
>
> On 2019-05-03, 12:09, "Nandor Kollar"
> 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 <
> katrin.skogl...@avanza.se>
> 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"
> > 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 <
> > katrin.skogl...@avanza.se>
> > 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" >
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > Since the last release of Apache Avro 1.8.2 on May 31,
> 2017. Two
> > years
> > > later,
> > > I'm thrilled
Re: [VOTE] Release Apache Avro 1.9.0 RC3
I realized I don't have a Jira account, should I sign up for one?
On 2019-05-03, 12:09, "Nandor Kollar" 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
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"
> 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 <
> katrin.skogl...@avanza.se>
> 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"
> 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:
> > *
Re: [VOTE] Release Apache Avro 1.9.0 RC3
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
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"
> 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 <
> katrin.skogl...@avanza.se>
> 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"
> 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/1294
> > * 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
> > *
Re: [VOTE] Release Apache Avro 1.9.0 RC3
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" 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
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" 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/1294
> * 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
Re: [VOTE] Release Apache Avro 1.9.0 RC3
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 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" 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/1294 > * 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 > > >
Re: [VOTE] Release Apache Avro 1.9.0 RC3
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" 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/1294 * 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
Re: [VOTE] Release Apache Avro 1.9.0 RC3
I am referring to the 'SNAPSHOT' suffix in the names (and content) of
the dist link.
https://dist.apache.org/repos/dist/dev/avro/avro-1.9.0-rc3/
It seems the github link is ok, but I assume that the 'defacto
version' for validation is the dist.apache.org one.
The binary staged artifacts look ok (the poms don't have the SNAPSHOT
suffix) so they should ok to test.
https://repository.apache.org/content/groups/staging/org/apache/avro/avro/1.9.0/
So maybe it is just a question of updating the files in dist.
Extra comment for the relase info 'avro-core' is now !MB smaller due
to the removal of the extra dependencies.
On Wed, May 1, 2019 at 10:39 PM Driesprong, Fokko wrote:
>
> Thank you Ismaël for looking into it and for the additional interesting
> info.
>
> Are you referring to the SNAPSHOT in the tests? I can remove these:
> root@83c927afb89b:/avro# grep -R "SNAPSHOT" .
> ./lang/js/node_modules/uglify-js/tools/domprops.json:
> "ORDERED_NODE_SNAPSHOT_TYPE",
> ./lang/js/node_modules/uglify-js/tools/domprops.json:
> "UNORDERED_NODE_SNAPSHOT_TYPE",
> ./lang/java/archetypes/avro-service-archetype/src/test/integration/projects/basic/archetype.properties:version=0.1-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/idl/pom-jsr310.xml:
> 1.9.0-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/idl/pom-joda.xml:
> 1.9.0-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/protocol/pom-jsr310.xml:
> 1.9.0-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/protocol/pom-joda.xml:
> 1.9.0-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/schema/pom-jsr310.xml:
> 1.9.0-SNAPSHOT
> ./lang/java/maven-plugin/src/test/resources/unit/schema/pom-joda.xml:
> 1.9.0-SNAPSHOT
> ./lang/ruby/Rakefile:VERSION =
> File.open('../../share/VERSION.txt').read.sub('-SNAPSHOT', '.pre1').chomp
> ./lang/ruby/.gem/gems/json_pure-2.1.0/data/prototype.js: null,
> XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
> ./doc/examples/java-example/pom.xml: 1.0-SNAPSHOT
>
> These have slipped the `mvn versions:set`.
>
> Cheers, Fokko
>
> Op di 30 apr. 2019 om 17:24 schreef Ismaël Mejía :
>
> > I did a quick review on the JIRA issues included and extracted some
> > extra interesting info worth of addint to the release notes. Up to you
> > to choose which matter or not to be added.
> >
> > * Remove Jackson classes from public API
> > * Avro is built by default with Java 8
> > * Avro is compiled and tested too with Java 11 to guarantee compatibility
> > * Avro MapReduce is also compiled and tested with Hadoop 3
> > * Avro is now leaner, multiple dependencies were removed: guava,
> > paranamer, commons-codec and commons-logging
> > * Introduce JMH Performance Testing Framework
> > * Add Snappy support for C++ DataFile
> >
> > On Tue, Apr 30, 2019 at 4:50 PM Ismaël Mejía wrote:
> > >
> > > Sorry, playing the killjoy again.
> > >
> > > It seems the files (and more critical the poms) still have the -SNAPSHOT
> > suffix.
> > > Also the comment of Dan Kulp about the extra directory structure in
> > > the main file build/avro-1.9.0 directory would be a nice extra thing
> > > to fix.
> > >
> > > On Tue, Apr 30, 2019 at 12:54 PM Driesprong, Fokko
> > 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/1294
> > > > * 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
Re: [VOTE] Release Apache Avro 1.9.0 RC3
Thank you Ismaël for looking into it and for the additional interesting
info.
Are you referring to the SNAPSHOT in the tests? I can remove these:
root@83c927afb89b:/avro# grep -R "SNAPSHOT" .
./lang/js/node_modules/uglify-js/tools/domprops.json:
"ORDERED_NODE_SNAPSHOT_TYPE",
./lang/js/node_modules/uglify-js/tools/domprops.json:
"UNORDERED_NODE_SNAPSHOT_TYPE",
./lang/java/archetypes/avro-service-archetype/src/test/integration/projects/basic/archetype.properties:version=0.1-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/idl/pom-jsr310.xml:
1.9.0-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/idl/pom-joda.xml:
1.9.0-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/protocol/pom-jsr310.xml:
1.9.0-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/protocol/pom-joda.xml:
1.9.0-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/schema/pom-jsr310.xml:
1.9.0-SNAPSHOT
./lang/java/maven-plugin/src/test/resources/unit/schema/pom-joda.xml:
1.9.0-SNAPSHOT
./lang/ruby/Rakefile:VERSION =
File.open('../../share/VERSION.txt').read.sub('-SNAPSHOT', '.pre1').chomp
./lang/ruby/.gem/gems/json_pure-2.1.0/data/prototype.js: null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
./doc/examples/java-example/pom.xml: 1.0-SNAPSHOT
These have slipped the `mvn versions:set`.
Cheers, Fokko
Op di 30 apr. 2019 om 17:24 schreef Ismaël Mejía :
> I did a quick review on the JIRA issues included and extracted some
> extra interesting info worth of addint to the release notes. Up to you
> to choose which matter or not to be added.
>
> * Remove Jackson classes from public API
> * Avro is built by default with Java 8
> * Avro is compiled and tested too with Java 11 to guarantee compatibility
> * Avro MapReduce is also compiled and tested with Hadoop 3
> * Avro is now leaner, multiple dependencies were removed: guava,
> paranamer, commons-codec and commons-logging
> * Introduce JMH Performance Testing Framework
> * Add Snappy support for C++ DataFile
>
> On Tue, Apr 30, 2019 at 4:50 PM Ismaël Mejía wrote:
> >
> > Sorry, playing the killjoy again.
> >
> > It seems the files (and more critical the poms) still have the -SNAPSHOT
> suffix.
> > Also the comment of Dan Kulp about the extra directory structure in
> > the main file build/avro-1.9.0 directory would be a nice extra thing
> > to fix.
> >
> > On Tue, Apr 30, 2019 at 12:54 PM Driesprong, Fokko
> 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/1294
> > > * 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
>
Re: [VOTE] Release Apache Avro 1.9.0 RC3
I did a quick review on the JIRA issues included and extracted some extra interesting info worth of addint to the release notes. Up to you to choose which matter or not to be added. * Remove Jackson classes from public API * Avro is built by default with Java 8 * Avro is compiled and tested too with Java 11 to guarantee compatibility * Avro MapReduce is also compiled and tested with Hadoop 3 * Avro is now leaner, multiple dependencies were removed: guava, paranamer, commons-codec and commons-logging * Introduce JMH Performance Testing Framework * Add Snappy support for C++ DataFile On Tue, Apr 30, 2019 at 4:50 PM Ismaël Mejía wrote: > > Sorry, playing the killjoy again. > > It seems the files (and more critical the poms) still have the -SNAPSHOT > suffix. > Also the comment of Dan Kulp about the extra directory structure in > the main file build/avro-1.9.0 directory would be a nice extra thing > to fix. > > On Tue, Apr 30, 2019 at 12:54 PM Driesprong, Fokko > 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/1294 > > * 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
Re: [VOTE] Release Apache Avro 1.9.0 RC3
Sorry, playing the killjoy again. It seems the files (and more critical the poms) still have the -SNAPSHOT suffix. Also the comment of Dan Kulp about the extra directory structure in the main file build/avro-1.9.0 directory would be a nice extra thing to fix. On Tue, Apr 30, 2019 at 12:54 PM Driesprong, Fokko 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/1294 > * 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
[VOTE] Release Apache Avro 1.9.0 RC3
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/1294 * 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
