avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kleppmann <mar...@kleppmann.com>
Subject Avro release cadence
Date Thu, 26 Jun 2014 12:02:06 GMT
Hi all,

Anecdotally, I think I have observed the following pattern of activity on the Avro project:

1. Not much happens for several months.
2. Doug announces that he wants to cut a release candidate soon.
3. Frenzied activity arises as everybody tries to get their patches into the release.
4. The release happens much later than planned, due to there being so many things that want
to get in.
5. Repeat.

For example, 1.7.7 was planned for "next week" over a month ago; 1.7.6 was planned for "later
this week" but took almost 6 weeks. The time between releases was about 6 months.

Whilst it's great that the prospect of a release can stimulate so much activity, I think it
would be good for the health of the Avro project, and good for our users, if releases were
smaller and more frequent. By all means we should keep the same backwards-compatibility rules;
but if there's a simple bugfix, we should be able to get it out sooner.

In particular, the currently-released version of Avro for Ruby (1.7.6) is totally broken --
it won't even install. (Major problems are https://issues.apache.org/jira/browse/AVRO-1499
and https://issues.apache.org/jira/browse/AVRO-1459 -- both have been fixed and are just awaiting
release). I'm embarrassed to tell my Ruby friends about Avro, because I have to preface it
with "I'm afraid it doesn't actually work". Consequently, there has been a fork (https://github.com/wvanbergen/tros)
with the express purpose of getting away from the Apache Avro release schedule.

It doesn't have to be this way. Please may I suggest the following:

(1) We aim to do point releases regularly, e.g. 1 or 2 releases per month, even if there haven't
been many commits in the meantime. As these will be small incremental releases, there will
be no rush to get a patch into this release, because you know that the next release isn't
far away. This ensures that bugfixes aren't withheld from users unnecessarily.

(2) If voting on releases so frequently is too much of a burden, we could decouple the point
version numbers for the different language implementations, so that different languages can
release independently, and only require voting on those that have changed. (I'm not sure whether
this is a good idea, or even compatible with ASF policy.)

What do you think?


View raw message