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? Best, Martin
signature.asc
Description: Message signed with OpenPGP using GPGMail
