Simon brought up compatibility as well. This is an existing problem and right now we have some interop tests where some languages generate data and then read all of the data from other languages. I don't think this problem changes much if we move to separate releases.
We can still run these tests, but could change them so that we update just one version of a particular language to pull in an RC and use released versions of other implementations. That could make it easier to spot problems because only one language is changing at a time. Of course, just having these tests doesn't mean they are kept up to date. Ruby's snappy implementation was incompatible with the others until recently. I think that overall, splitting the projects won't result in a noticeable change in interoperability. rb On Mon, Nov 21, 2016 at 10:20 AM, Zoltan Ivanfi <z...@cloudera.com> wrote: > Hi, > > A question just came to my mind: How would inter-language compatibility > work after the split? How will we now which versions of the different > language bindings support the same features and allow bidirectional > exchange of data? > > Or is it an already existing problem? I don't know too much about the > language bindings you mentioned; if some of them have not been worked on > recently, does this mean that they are lacking in support for some features > of the specification? If I use libraries from the same release of Avro in > software components of different languages, are they not guaranteed to be > compatible with each other? > > Thanks, > > Zoltan > > On Sat, Nov 19, 2016 at 10:03 PM Ryan Blue <rb...@netflix.com.invalid> > wrote: > > > This is in response to Tom's concerns: > > > > > When I did the 1.8.0 release I had to fix a few failing tests for a > > couple of languages, but it was mainly just doing library updates. > > > > I think there will be less trouble with builds if we have separate > > releases, but my main motivation is to avoid languages blocking one > another > > and make it possible to get more releases out. I think we could have had > > several JavaScript releases this year if JS could have been released > > independently, but the rest of the community isn't moving fast enough for > > that. And that's fine; we need to fix bugs in C before we put out a C > > release, but we don't want C to prevent other language contributors from > > moving forward. > > > > > I'm not at all convinced that splitting the project into per-language > > pieces > > will help. It will be a lot of work and I think we'll just get lots of > > orphaned languages that never get released. > > > > Splitting does two positive things: it allows releases to happen > > independently and it makes maintenance and contribution easier. > > > > Independent releases are a net positive, in my opinion. It is important > to > > get contributions into releases so that contributors benefit from their > > work. Otherwise, what is the incentive to contribute back? Releasing > > implementations independently allows us to get contributions back to the > > community faster and decreases the likelihood that someone loses interest > > because they don't get to use what they fixed. > > > > I think that a better release cadence for active languages outweighs the > > cost of orphaned languages. I agree that it's likely for, say, PHP to not > > be released again. But what is the value of releasing code that hasn't > > changed? Splitting would no longer push us to periodically fix languages > > when they break, but this irregular maintenance isn't substantially > > different than having no releases. I think there's a strong case that it > is > > better for downstream consumers to see that the version number hasn't > > changed rather than having one identical release after another that > gives a > > false sense that the implementation is actively maintained. > > > > The second positive effect of splitting from above is to make maintenance > > and contribution easier. A good example is adding more environments to CI > > tests. We aren't going to add 3 versions of Ruby to the Docker image, but > > it's simple to set up in a CI environment for typical Ruby projects. > > Language-specific repositories allow us to take better advantage of > > existing tools, while structuring each repository for people familiar > with > > that language, making it easier for the people most likely to contribute > to > > do so. I know it isn't horribly difficult today, but I think it's a step > in > > the right direction to make this easier. > > > > rb > > > > On Wed, Nov 16, 2016 at 8:41 PM, Sean Busbey <bus...@cloudera.com> > wrote: > > > > > On Tue, Nov 15, 2016 at 3:45 PM, Doug Cutting <cutt...@gmail.com> > wrote: > > > > On Mon, Nov 14, 2016 at 8:40 PM, Ryan Blue <rb...@netflix.com.invalid > > > > > wrote: > > > >> we don't have enough votes for a release > > > > > > > > I don't think that's true. You might not have gotten enough votes > > > > within a few days. I too have had that problem for several releases. > > > > But when that happened I would send personal messages to a few PMC > > > > members asking them if they had time to please review a release. > Some > > > > PMC members get busy with other things and fall behind on Avro > emails. > > > > A few reminders never failed to rouse enough reviews & votes. > > > > > > > > > > In HBase we've largely switched away from release votes that have a > > > fixed deadline due to the need to corral PMC votes. > > > > > > Instead, we now state the minimum voting period (almost always 72hrs > > > per ASF policy) and set a courtesy notice of when the RM would like to > > > close the vote. Then we just keep pinging private@ or individuals > > > until we get enough votes for a result, or find something to start > > > getting -1s. > > > > > > We could try something like that for a bit to see if "flog the bushes > > > for PMC participation" is enough to keep us on a steady stream of > > > releases. > > > > > > It would also probably help to make explicit to the community that > > > showing up to test and vote on RCs is "acting like a PMC" in the eyes > > > of some number of current PMC members (it is for me, for example). > > > > > > -- > > > busbey > > > > > > > > > > > -- > > Ryan Blue > > Software Engineer > > Netflix > > > -- Ryan Blue Software Engineer Netflix
