Re: Decimal type, limitation on scale

[Zoltan Farkas]

+dev adding the dev mailing list, maybe somebody there can answer the reasoning.

when comparing sql server with Oracle and Postgress: 

https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-ver15
 

 

https://docs.oracle.com/cd/A84870_01/doc/server.816/a76965/c10datyp.htm#743 

https://www.postgresql.org/docs/9.1/datatype-numeric.html 



One allows for negative scale, the other doesn’t.
My biggest issue with the current decimal spec is that it does not encode the 
scale (uses the scale defined in the schema), as such it cannot accommodate a 
Oracle and Postgres NUMBER without scale coercion. 

there are other differences (like NAN, …) 

But there is no reason why the decimal2 logical type should not be created to 
address the above…

or even better promote decimal to a first class 
type...https://issues.apache.org/jira/browse/AVRO-2164 
 


—Z

> On Mar 2, 2020, at 2:34 PM, Christopher Egerton  wrote:
> 
> Hi all,
> 
> I've been trying to do some research on the logical decimal type and why the 
> scale of a decimal type must be between zero and the precision of the type, 
> inclusive. The ticket https://issues.apache.org/jira/browse/AVRO-1402 
>  has a lot of discussion 
> around the design of the type, but I haven't been able to find any rationale 
> for the limitations on the scale of the type.
> 
> These don't appear to align with existing conventions for precision and scale 
> in the context of SQL numeric types, the JDBC API, and the Java standard 
> library's BigDecimal class. In these contexts, the precision must be a 
> positive number, but the scale can be any value--positive (representing the 
> number of digits of precision that are available after the decimal point), 
> negative (representing the number of trailing zeroes at the end of the number 
> before an implicit decimal point), or zero. It is not bounded by the 
> precision of the type.
> 
> The definitions for scale and precision appear to align across these 
> contexts, including the Avro spec, so I'm curious as to why the Avro 
> spec--seemingly an anomaly--is the only one to declare these limitations on 
> what the scale of a decimal type can be.
> 
> Does anyone know why these exist, and if not, would it be okay to file a 
> ticket to remove them from the spec and begin work on it?
> 
> Cheers,
> 
> Chris

Re: [DISCUSS] version numbers and where changes should land

[Ryan Blue]

+1 for incrementing the major number for library compatibility changes and
decoupling the release versions across languages.

I agree with the points that Sean made. This is confusing for users, and
needlessly so because there is only one binary format and I don't think
there are major pushes to introduce a breaking change.

On Mon, Mar 2, 2020 at 7:48 AM Sean Busbey  wrote:

> > So, as I understand it. The whole 1.x version should be binary
> compatible.
>
> the term "binary compatible" is overloaded, thanks to our
> participation in the Java ecosystem. Every data file written in Avro
> 1.y is intended to be readable by every other Avro 1.y release,
> regardless of language. That is true even if we know that there are
> cases where errors in various language libraries has prevented
> success.
>
> In Java ecosystem parlance the term "binary compatible" also refers to
> the ability to use a Java library in place of another without needing
> to recompile any code that refers to said library. It is definitely
> not the case that every Avro 1.y Java version has been binary
> compatible in this sense (in fact just the opposite).
>
> > For 1.9 we broke some of the API's because, at the time, the decision was
> > that removing Jackson from the public API was required to move from
> > Codehaus jackson (1.x) to the Fasterxml one (2.x). The public API
> shouldn't
> > have exposed these methods in the first place.
>
> I think this is confusing the two issues of "compatibility of
> serialized bytes" and "compatibility of language APIs". This is part
> of why I think we should stop relying on the first version number to
> indicate "compatibility of serialized bytes".
>
> > I wouldn't be in favor of switching to 10.x (dropping the 1. in front of
> > it). What's the added value in this? I'm just afraid of changing this,
> > would confuse a lot of downstream users.
>
> The big advantage is that literally everywhere else in the software
> ecosystems I've seen the first number in a version string is either
> "major version" or "marketing version", usually the former. Folks
> expect that if that version number hasn't changed then they should be
> able to "easily" upgrade to use the newer library. In Avro that
> plainly isn't true. I can think of multiple cases where other ASF
> projects have gotten surprised that going from e.g. Java libraries for
> Avro 1.7 to Avro 1.8 was a major version bump.
>
> I agree that going from 1.x.y to 10.y.z might be confusing due to the
> large number jump. I think going to "2.y.z" would clearly indicate
> folks needed to pay attention to a version difference because the
> first number changed. When we have their attention we can explain that
> we're using it as major version from now on.
>
>
> > Also, a similar discussion was on the Spark devlist, I think Michael has
> > some valid points here:
> > https://mail-archives.apache.org/mod_mbox/spark-dev/202002.mbox/browser
>
> This is a month of email from dev@spark. Could you link to a specific
> thread on lists.apache.org or provide a subject line?
>
> On Mon, Mar 2, 2020 at 3:00 AM Driesprong, Fokko 
> wrote:
> >
> > So, as I understand it. The whole 1.x version should be binary
> compatible.
> > So anything is written with Java 1.x should be readable with Python 1.x.
> > We've been working on extending the integration tests as well.
> >
> > Not all languages support all the features, for example, many languages
> > lack support for logical types. In this case, a datetime would be just
> read
> > as an integer, so there is a fallback scenario.
> >
> > For 1.9 we broke some of the API's because, at the time, the decision was
> > that removing Jackson from the public API was required to move from
> > Codehaus jackson (1.x) to the Fasterxml one (2.x). The public API
> shouldn't
> > have exposed these methods in the first place.
> >
> > I wouldn't be in favor of switching to 10.x (dropping the 1. in front of
> > it). What's the added value in this? I'm just afraid of changing this,
> > would confuse a lot of downstream users.
> >
> > Also, a similar discussion was on the Spark devlist, I think Michael has
> > some valid points here:
> > https://mail-archives.apache.org/mod_mbox/spark-dev/202002.mbox/browser
> >
> > Maybe it is good to formalize our policy, and put it on the website.
> >
> > Cheers, Fokko Driesprong
> >
> > Op vr 28 feb. 2020 om 17:53 schreef Sean Busbey :
> >
> > > Counterpoint on independently versioning the various languages. Do we
> > > know if Python Avro X works with Java Avro Y as it is? It seems like
> > > we already get surprised pretty often when they don't.
> > >
> > > If we stop including the "data compatibility version" or whatever
> > > we're calling the first number, we'll need to get more formal on
> > > versioning the specification and having libraries plainly label which
> > > specification(s) they comport to.
> > >
> > > At the very least it seems like we'd make the _easy_ path easier for
> > > the languages 

[jira] [Created] (AVRO-2768) Python Avro cannot be imported when packaged as a zip-file

[Carl Vander (Jira)]

Carl Vander created AVRO-2768:
-

 Summary: Python Avro cannot be imported when packaged as a zip-file
 Key: AVRO-2768
 URL: https://issues.apache.org/jira/browse/AVRO-2768
 Project: Apache Avro
  Issue Type: Bug
  Components: python
Affects Versions: 1.9.2
Reporter: Carl Vander


Hi,

When running a Spark job I am packaging all Python dependencies in a zip-file 
which is distributed to the nodes. I am using AWS Glue to execute the Spark job.

One of the dependencies included is the python package avro-python3. However, 
this cannot be used since VERSION.txt cannot be opened when the package is 
included as a zip. It errors out in __init__.py when trying to open the file. 
The file VERSION.txt is present, however the path given to open() looks 
something like "/home/user/custom-site-package.zip/avro/VERSION.txt".

On a side note, the package has zip_safe set to true, so I expect this to work 
:)

I have opened a PR on Github with a possible solution.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2767) Can't easily use Java annotations to set enum default

[Rich DiCroce (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rich DiCroce updated AVRO-2767:
---
Issue Type: Improvement  (was: Bug)

> Can't easily use Java annotations to set enum default
> -
>
> Key: AVRO-2767
> URL: https://issues.apache.org/jira/browse/AVRO-2767
> Project: Apache Avro
>  Issue Type: Improvement
>  Components: java
>Affects Versions: 1.9.2
>Reporter: Rich DiCroce
>Priority: Major
>
> 1.9.0 introduced support for enum default values. There's currently not an 
> easy way to set an enum's default value when using Java annotations:
>  * AvroDefault cannot be applied to a class.
>  * AvroMeta can be applied to a class, but has no effect on an enum class. 
> Not sure if that's a bug or not. Even if it could, "default" is a reserved 
> name so presumably that would cause an error.
> The only solution I can find is to apply AvroSchema to the enum class and 
> define everything, even though the only thing I want to set is the default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (AVRO-2767) Can't easily use Java annotations to set enum default

[Rich DiCroce (Jira)]

Rich DiCroce created AVRO-2767:
--

 Summary: Can't easily use Java annotations to set enum default
 Key: AVRO-2767
 URL: https://issues.apache.org/jira/browse/AVRO-2767
 Project: Apache Avro
  Issue Type: Bug
  Components: java
Affects Versions: 1.9.2
Reporter: Rich DiCroce


1.9.0 introduced support for enum default values. There's currently not an easy 
way to set an enum's default value when using Java annotations:
 * AvroDefault cannot be applied to a class.
 * AvroMeta can be applied to a class, but has no effect on an enum class. Not 
sure if that's a bug or not. Even if it could, "default" is a reserved name so 
presumably that would cause an error.

The only solution I can find is to apply AvroSchema to the enum class and 
define everything, even though the only thing I want to set is the default.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] version numbers and where changes should land

[Sean Busbey]

> So, as I understand it. The whole 1.x version should be binary compatible.

the term "binary compatible" is overloaded, thanks to our
participation in the Java ecosystem. Every data file written in Avro
1.y is intended to be readable by every other Avro 1.y release,
regardless of language. That is true even if we know that there are
cases where errors in various language libraries has prevented
success.

In Java ecosystem parlance the term "binary compatible" also refers to
the ability to use a Java library in place of another without needing
to recompile any code that refers to said library. It is definitely
not the case that every Avro 1.y Java version has been binary
compatible in this sense (in fact just the opposite).

> For 1.9 we broke some of the API's because, at the time, the decision was
> that removing Jackson from the public API was required to move from
> Codehaus jackson (1.x) to the Fasterxml one (2.x). The public API shouldn't
> have exposed these methods in the first place.

I think this is confusing the two issues of "compatibility of
serialized bytes" and "compatibility of language APIs". This is part
of why I think we should stop relying on the first version number to
indicate "compatibility of serialized bytes".

> I wouldn't be in favor of switching to 10.x (dropping the 1. in front of
> it). What's the added value in this? I'm just afraid of changing this,
> would confuse a lot of downstream users.

The big advantage is that literally everywhere else in the software
ecosystems I've seen the first number in a version string is either
"major version" or "marketing version", usually the former. Folks
expect that if that version number hasn't changed then they should be
able to "easily" upgrade to use the newer library. In Avro that
plainly isn't true. I can think of multiple cases where other ASF
projects have gotten surprised that going from e.g. Java libraries for
Avro 1.7 to Avro 1.8 was a major version bump.

I agree that going from 1.x.y to 10.y.z might be confusing due to the
large number jump. I think going to "2.y.z" would clearly indicate
folks needed to pay attention to a version difference because the
first number changed. When we have their attention we can explain that
we're using it as major version from now on.


> Also, a similar discussion was on the Spark devlist, I think Michael has
> some valid points here:
> https://mail-archives.apache.org/mod_mbox/spark-dev/202002.mbox/browser

This is a month of email from dev@spark. Could you link to a specific
thread on lists.apache.org or provide a subject line?

On Mon, Mar 2, 2020 at 3:00 AM Driesprong, Fokko  wrote:
>
> So, as I understand it. The whole 1.x version should be binary compatible.
> So anything is written with Java 1.x should be readable with Python 1.x.
> We've been working on extending the integration tests as well.
>
> Not all languages support all the features, for example, many languages
> lack support for logical types. In this case, a datetime would be just read
> as an integer, so there is a fallback scenario.
>
> For 1.9 we broke some of the API's because, at the time, the decision was
> that removing Jackson from the public API was required to move from
> Codehaus jackson (1.x) to the Fasterxml one (2.x). The public API shouldn't
> have exposed these methods in the first place.
>
> I wouldn't be in favor of switching to 10.x (dropping the 1. in front of
> it). What's the added value in this? I'm just afraid of changing this,
> would confuse a lot of downstream users.
>
> Also, a similar discussion was on the Spark devlist, I think Michael has
> some valid points here:
> https://mail-archives.apache.org/mod_mbox/spark-dev/202002.mbox/browser
>
> Maybe it is good to formalize our policy, and put it on the website.
>
> Cheers, Fokko Driesprong
>
> Op vr 28 feb. 2020 om 17:53 schreef Sean Busbey :
>
> > Counterpoint on independently versioning the various languages. Do we
> > know if Python Avro X works with Java Avro Y as it is? It seems like
> > we already get surprised pretty often when they don't.
> >
> > If we stop including the "data compatibility version" or whatever
> > we're calling the first number, we'll need to get more formal on
> > versioning the specification and having libraries plainly label which
> > specification(s) they comport to.
> >
> > At the very least it seems like we'd make the _easy_ path easier for
> > the languages that are well maintained. Sure it'll be burden on those
> > languages that aren't well maintained, but it seems like those are
> > already in that position?
> >
> > On Thu, Feb 27, 2020 at 9:13 AM Ismaël Mejía  wrote:
> > >
> > > Bringing my comment from the JIRA ticket here for discussion:
> > >
> > > > "One argument against semantic versioning is the fact that Avro
> > supports
> > > 9 language APIs, so if let's say C++ breaks its backwards compatibility
> > > should we move the version number up for every single language? Sounds
> > like
> > > a burden and 

[jira] [Updated] (AVRO-2766) [C++] Compilation failure size_t

[Laurent Stacul (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Laurent Stacul updated AVRO-2766:
-
Description: 
With the following system:
{code:java}
$ uname -a
Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 10.0.1 20200220 (experimental){code}
 

I received the compilation error:
{code:java}
g++  -DAVRO_SOURCE 
-I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api
 
-I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/build
 
-I/home/docker/development/opensource-pack-builder/components/avro/DEPS/osp/Boost/latest/osp/include
  -DNDEBUG -O3 -std=gnu++2a -fno-working-directory -ggdb3 -flto 
-ffat-lto-objects -fuse-linker-plugin -Wall -O3 -DNDEBUG   -std=c++11 -fPIC -o 
CMakeFiles/avrocpp_s.dir/impl/Zigzag.cc.o -c 
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc

In file included from 
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:37:11:
 error: 'size_t' does not name a type
 37 | AVRO_DECL size_t encodeInt32(int32_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:26:1:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?
 25 | #include "Config.hh"
 +++ |+#include 
 26 | /// \file
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 error: 'size_t' does not name a type
 38 | AVRO_DECL size_t encodeInt64(int64_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?{code}
Regards,

Laurent

 

  was:
With the following system:
{code:java}
$ uname -a
Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 10.0.1 20200220 (experimental){code}
 

I received the compilation error:
{code:java}
In file included from 
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:37:11:
 error: 'size_t' does not name a type
 37 | AVRO_DECL size_t encodeInt32(int32_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:26:1:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?
 25 | #include "Config.hh"
 +++ |+#include 
 26 | /// \file
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 error: 'size_t' does not name a type
 38 | AVRO_DECL size_t encodeInt64(int64_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?{code}
Regards,

Laurent

 


> [C++] Compilation failure size_t
> 
>
> Key: AVRO-2766
> URL: https://issues.apache.org/jira/browse/AVRO-2766
> Project: Apache Avro
>  Issue Type: Bug
>  Components: build, c++
>Affects Versions: 1.9.2
>Reporter: Laurent Stacul
>Priority: Major
>
> With the following system:
> {code:java}
> $ uname -a
> Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 
> 2020 x86_64 x86_64 x86_64 GNU/Linux
> $ gcc --version
> gcc (GCC) 10.0.1 20200220 (experimental){code}
>  
> I received the compilation error:
> {code:java}
> g++  -DAVRO_SOURCE 
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/build
>  
> -I/home/docker/development/opensource-pack-builder/components/avro/DEPS/osp/Boost/latest/osp/include
>   -DNDEBUG -O3 -std=gnu++2a -fno-working-directory -ggdb3 -flto 
> -ffat-lto-objects -fuse-linker-plugin -Wall -O3 -DNDEBUG   -std=c++11 -fPIC 
> -o CMakeFiles/avrocpp_s.dir/impl/Zigzag.cc.o -c 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc
> In file included from 
> /home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
> 

[jira] [Created] (AVRO-2766) [C++] Compilation failure size_t

[Laurent Stacul (Jira)]

Laurent Stacul created AVRO-2766:


 Summary: [C++] Compilation failure size_t
 Key: AVRO-2766
 URL: https://issues.apache.org/jira/browse/AVRO-2766
 Project: Apache Avro
  Issue Type: Bug
  Components: build, c++
Affects Versions: 1.9.2
Reporter: Laurent Stacul


With the following system:
{code:java}
$ uname -a
Linux edf2927682ca 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 10.0.1 20200220 (experimental){code}
 

I received the compilation error:
{code:java}
In file included from 
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/impl/Zigzag.cc:20:
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:37:11:
 error: 'size_t' does not name a type
 37 | AVRO_DECL size_t encodeInt32(int32_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:26:1:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?
 25 | #include "Config.hh"
 +++ |+#include 
 26 | /// \file
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 error: 'size_t' does not name a type
 38 | AVRO_DECL size_t encodeInt64(int64_t input, std::array 
);
 | ^~
/home/docker/development/opensource-pack-builder/components/avro/BUILD/avro-src-1.9.2/lang/c++/api/Zigzag.hh:38:11:
 note: 'size_t' is defined in header ''; did you forget to '#include 
'?{code}
Regards,

Laurent

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSS] version numbers and where changes should land

[Driesprong, Fokko]

So, as I understand it. The whole 1.x version should be binary compatible.
So anything is written with Java 1.x should be readable with Python 1.x.
We've been working on extending the integration tests as well.

Not all languages support all the features, for example, many languages
lack support for logical types. In this case, a datetime would be just read
as an integer, so there is a fallback scenario.

For 1.9 we broke some of the API's because, at the time, the decision was
that removing Jackson from the public API was required to move from
Codehaus jackson (1.x) to the Fasterxml one (2.x). The public API shouldn't
have exposed these methods in the first place.

I wouldn't be in favor of switching to 10.x (dropping the 1. in front of
it). What's the added value in this? I'm just afraid of changing this,
would confuse a lot of downstream users.

Also, a similar discussion was on the Spark devlist, I think Michael has
some valid points here:
https://mail-archives.apache.org/mod_mbox/spark-dev/202002.mbox/browser

Maybe it is good to formalize our policy, and put it on the website.

Cheers, Fokko Driesprong

Op vr 28 feb. 2020 om 17:53 schreef Sean Busbey :

> Counterpoint on independently versioning the various languages. Do we
> know if Python Avro X works with Java Avro Y as it is? It seems like
> we already get surprised pretty often when they don't.
>
> If we stop including the "data compatibility version" or whatever
> we're calling the first number, we'll need to get more formal on
> versioning the specification and having libraries plainly label which
> specification(s) they comport to.
>
> At the very least it seems like we'd make the _easy_ path easier for
> the languages that are well maintained. Sure it'll be burden on those
> languages that aren't well maintained, but it seems like those are
> already in that position?
>
> On Thu, Feb 27, 2020 at 9:13 AM Ismaël Mejía  wrote:
> >
> > Bringing my comment from the JIRA ticket here for discussion:
> >
> > > "One argument against semantic versioning is the fact that Avro
> supports
> > 9 language APIs, so if let's say C++ breaks its backwards compatibility
> > should we move the version number up for every single language? Sounds
> like
> > a burden and in particular a not easy task to track since we do not have
> > proper validation of breaking changes in place for every language at this
> > point.
> > > ... (even if we separate release numbers per language) that seems like
> a
> > lot of work for probably a similar output because then users will doubt,
> > wait is Python Avro 3.1.0 compatible with Java Avro 5.2.0? and they will
> > probably be for the binary format."
> >
> > Also there is the case of interop tests, how will those act in this case.
> > We will need a compatibility matrix, again I am not sure if it is the
> best
> > approach, looks like lots of work for not much in return.
> >
> >
> >
> > On Thu, Feb 27, 2020 at 12:21 PM Ryan Skraba  wrote:
> >
> > > Hello!  Resurrecting -- I think this was the last thread bringing up
> this
> > > issue!
> > >
> > > Since we've talked about releasing 1.10.x in May, and it's a nice
> > > round number... what do you think about
> > >
> > > 1) finally dropping the prefix for the "specification version" and
> > > calling it Avro 10.x
> > >
> > > 2) committing to semantic versioning for future releases
> > >
> > > I can see this being a hugely positive move for aligning with the
> > > expectations of developers and projects... but it leads to a lot of
> > > questions about releasing all the artifacts together.
> > >
> > > There's already a JIRA:
> https://issues.apache.org/jira/browse/AVRO-2687
> > >
> > > Ryan
> > >
> > > On Fri, Sep 13, 2019 at 12:00 PM Driesprong, Fokko
> 
> > > wrote:
> > > >
> > > > Thanks Sean for bringing this up.
> > > >
> > > > For the 1.9 branch there were some incompatible changes in the API
> with
> > > > respect to 1.8.2. We've removed Jackson
> > > >  and Netty from the public
> API.
> > > > This is actually breaking some of the builds
> > > > , so,
> > > unfortunately,
> > > > it isn't compatible, and therefore the major version bump.
> > > >
> > > > The 1.9.x branch still has support for the Joda time library, but
> > > defaults
> > > > to jsr310, but is still compatible (I believe). For 1.10 the plan is
> to
> > > > completely remove Joda from the codebase since it is officially
> > > deprecated
> > > > in favor of Java8 time (jsr310). A lot of this stuff is just changes
> to
> > > the
> > > > Java API of Avro, which mostly involves changes to the LogicalTypes,
> so
> > > the
> > > > actual format is still compatible (as it should).
> > > >
> > > > I agree with you Sean, that a lot of the changes that are targeted
> for
> > > 1.10
> > > > could be cherry-picked back to the 1.9 branch. If someone is willing
> to
> > > do
> > > > this, I would be grateful. However, maintaining 

[jira] [Commented] (AVRO-1461) Distribute Perl API on CPAN

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048879#comment-17048879
 ] 

Hudson commented on AVRO-1461:
--

SUCCESS: Integrated in Jenkins build AvroJava #838 (See 
[https://builds.apache.org/job/AvroJava/838/])
AVRO-1461: Distribute Perl API on CPAN (#824) (github: 
[https://github.com/apache/avro/commit/9741c08ae2ffe06adbf3559b5c5702d9bf8cae3c])
* (edit) lang/perl/build.sh
* (edit) lang/perl/lib/Avro/Protocol.pm
* (edit) lang/perl/Makefile.PL
* (edit) lang/perl/lib/Avro/DataFileWriter.pm
* (edit) lang/perl/lib/Avro/BinaryEncoder.pm
* (edit) lang/perl/lib/Avro/DataFileReader.pm
* (edit) lang/perl/MANIFEST
* (edit) lang/perl/lib/Avro/Protocol/Message.pm
* (edit) lang/perl/lib/Avro/BinaryDecoder.pm
* (edit) lang/perl/lib/Avro/Schema.pm
* (edit) lang/perl/lib/Avro/DataFile.pm


> Distribute Perl API on CPAN
> ---
>
> Key: AVRO-1461
> URL: https://issues.apache.org/jira/browse/AVRO-1461
> Project: Apache Avro
>  Issue Type: Wish
>  Components: perl
>Reporter: John Karp
>Assignee: Kengo Seki
>Priority: Minor
> Fix For: 1.10.0
>
>
> Having a package for the Perl Avro API distributed on CPAN would increase the 
> visibility and convenience of the Avro project to the Perl world 
> significantly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2759) Fix Ruby test not to redefine a function with the same name

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048880#comment-17048880
 ] 

Hudson commented on AVRO-2759:
--

SUCCESS: Integrated in Jenkins build AvroJava #838 (See 
[https://builds.apache.org/job/AvroJava/838/])
AVRO-2759: Fix Ruby test not to redefine a function with the same name (github: 
[https://github.com/apache/avro/commit/791ec6017b03e3cc79fbf546dd9d79d20d476b4e])
* (edit) lang/ruby/test/test_schema_validator.rb


> Fix Ruby test not to redefine a function with the same name
> ---
>
> Key: AVRO-2759
> URL: https://issues.apache.org/jira/browse/AVRO-2759
> Project: Apache Avro
>  Issue Type: Test
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Trivial
> Fix For: 1.10.0
>
>
> Running {{./build.sh test}} in the {{lang/ruby}} directory shows the 
> following warnings.
> {code}
> #
> # Run tests: /avro/lang/ruby/ 
> #
> (snip)
> /avro/lang/ruby/test/test_schema.rb:20: warning: method redefined; discarding 
> old hash_to_schema
> /avro/lang/ruby/test/test_schema_validator.rb:28: warning: previous 
> definition of hash_to_schema was here
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (AVRO-2759) Fix Ruby test not to redefine a function with the same name

[Ryan Skraba (Jira)]

 [ 
https://issues.apache.org/jira/browse/AVRO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ryan Skraba updated AVRO-2759:
--
Fix Version/s: 1.10.0
   Resolution: Fixed
   Status: Resolved  (was: Patch Available)

Thanks for the fix!

> Fix Ruby test not to redefine a function with the same name
> ---
>
> Key: AVRO-2759
> URL: https://issues.apache.org/jira/browse/AVRO-2759
> Project: Apache Avro
>  Issue Type: Test
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Trivial
> Fix For: 1.10.0
>
>
> Running {{./build.sh test}} in the {{lang/ruby}} directory shows the 
> following warnings.
> {code}
> #
> # Run tests: /avro/lang/ruby/ 
> #
> (snip)
> /avro/lang/ruby/test/test_schema.rb:20: warning: method redefined; discarding 
> old hash_to_schema
> /avro/lang/ruby/test/test_schema_validator.rb:28: warning: previous 
> definition of hash_to_schema was here
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-2759) Fix Ruby test not to redefine a function with the same name

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048873#comment-17048873
 ] 

ASF subversion and git services commented on AVRO-2759:
---

Commit 791ec6017b03e3cc79fbf546dd9d79d20d476b4e in avro's branch 
refs/heads/master from Kengo Seki
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=791ec60 ]

AVRO-2759: Fix Ruby test not to redefine a function with the same name (#828)



> Fix Ruby test not to redefine a function with the same name
> ---
>
> Key: AVRO-2759
> URL: https://issues.apache.org/jira/browse/AVRO-2759
> Project: Apache Avro
>  Issue Type: Test
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Trivial
>
> Running {{./build.sh test}} in the {{lang/ruby}} directory shows the 
> following warnings.
> {code}
> #
> # Run tests: /avro/lang/ruby/ 
> #
> (snip)
> /avro/lang/ruby/test/test_schema.rb:20: warning: method redefined; discarding 
> old hash_to_schema
> /avro/lang/ruby/test/test_schema_validator.rb:28: warning: previous 
> definition of hash_to_schema was here
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (AVRO-1461) Distribute Perl API on CPAN

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/AVRO-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17048868#comment-17048868
 ] 

ASF subversion and git services commented on AVRO-1461:
---

Commit 9741c08ae2ffe06adbf3559b5c5702d9bf8cae3c in avro's branch 
refs/heads/master from Kengo Seki
[ https://gitbox.apache.org/repos/asf?p=avro.git;h=9741c08 ]

AVRO-1461: Distribute Perl API on CPAN (#824)

Thanks so much!

> Distribute Perl API on CPAN
> ---
>
> Key: AVRO-1461
> URL: https://issues.apache.org/jira/browse/AVRO-1461
> Project: Apache Avro
>  Issue Type: Wish
>  Components: perl
>Reporter: John Karp
>Assignee: Kengo Seki
>Priority: Minor
> Fix For: 1.10.0
>
>
> Having a package for the Perl Avro API distributed on CPAN would increase the 
> visibility and convenience of the Avro project to the Perl world 
> significantly.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)