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

[Driesprong, Fokko]

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 a lot of different branches
is quite time-consuming in terms of release management of the different
versions. For Apache Avro 1.9.0 we actually had some regression bugs which
were blocking, therefore the 1.9.1 release.

Personally I don't have big objection on bumping the major version if there
are breaking changes to one of the API's. But a big +1 on having a
standardized approach on the versioning, this also includes a more clear
approach on documenting the upgrade process and a better changelog. I've
added summaries of the releases a the Github releases:
https://github.com/apache/avro/releases but I think having this on the Avro
website might be more appropriate.

Cheers, Fokko Driesprong



Op wo 11 sep. 2019 om 18:17 schreef Ryan Blue :

> > What would it look like if we *did* have to make an incompatible data
> format change after adopting "conventional" library version strings?
>
> Let's call these format v1 and v2. The library must produce v1 by default,
> so it's a matter of having support for writing v2. When the default
> changes to v2, then that behavior change would require a major version
> increase to signal changes to compatibility. I think we would also want
> clear documentation for each version that shows what versions of the format
> it can read, write, and what it will use by default. A table on the site
> would work.
>
> On Tue, Sep 10, 2019 at 2:51 PM Sean Busbey  wrote:
>
> > What would it look like if we *did* have to make an incompatible data
> > format change after adopting "conventional" library version strings?
> >
> > What if we version the specification independent from the libraries
> > and then have the docs for the libraries claim spec version
> > compatibility?
> >
> > On Tue, Sep 10, 2019 at 3:55 PM Ryan Blue 
> > wrote:
> > >
> > > +1 for changing the version strings to follow a more standard
> convention.
> > > We don't have any breaking format changes, so I think it is expected
> that
> > > the format compatibility version won't change.
> > >
> > > On Tue, Sep 10, 2019 at 7:28 AM Sean Busbey  wrote:
> > >
> > > > Hi folks!
> > > >
> > > > historically, Avro version numbers have had the form:
> > > >
> > > >  .  .  > version>
> > > >
> > > > That is, the first number says wether or not we expect data
> > > > serialization to be compatible, and the second to say wether we
> expect
> > > > some library will be backwards incompatible however that's defined
> for
> > > > the library's language. For example, in the Java library when we make
> > > > changes to public method signatures such that folks can't just swap
> > > > out jar files of our implementation.
> > > >
> > > > While getting myself up to speed on the state of our release lines, I
> > > > noticed we already have the 1.9 release line in a branch, with master
> > > > set up for the next major library version. JIRA shows ~46 issues that
> > > > are in 1.10 but not in a 1.9 release[1].
> > > >
> > > > I haven't looked at all of them yet, but the few I sampled don't see
> > > > to require a major version increment.
> > > >
> > > > I looked around our site and I also can't find anywhere that we've
> > > > documented our version strings. I know I've been in discussions in
> > > > other communities where our version strings have been surprising.
> e.g.
> > > > folks had assumed they can do a low-effort upgrade from 1.7 to 1.8
> > > > only to find that there were documented incompatibilities and
> behavior
> > > > changes.
> > > >
> > > > Are we actively planning on rolling out 1.10? (like, do we have a
> goal
> > > > date?)
> > > >
> > > > I know that when 1.9 went out we EOLed 1.7 and 1.8 in part due to the
> > > > overhead of trying to maintain multiple release lines (especially
> once
> > > > that had so much baggage) while we're trying to reestablish good
> > > > habits on release cadence. How many major version are we planning to
> > > > keep going once 1.10 is ready?
> > > >
> > > > What do folks think about 

[jira] [Updated] (AVRO-2546) Add bzip2 and xz support to the Python3 bindings

[Fokko Driesprong (Jira)]

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

Fokko Driesprong updated AVRO-2546:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Add bzip2 and xz support to the Python3 bindings
> 
>
> Key: AVRO-2546
> URL: https://issues.apache.org/jira/browse/AVRO-2546
> Project: Apache Avro
>  Issue Type: New Feature
>  Components: python
>Reporter: Kengo Seki
>Assignee: Kengo Seki
>Priority: Major
> Fix For: 1.10.0
>
>
> Only the Java bindings support bzip2 and xz codecs for now, but these codecs 
> may be useful in the case that compression ratio has the highest priority.
>  Let's add support for them to other languages.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)