we are currently blocked on all releases because of licensing errors in under-maintained libraries.
https://issues.apache.org/jira/browse/AVRO-1722 essentially Ryan and I slowly work our way through understanding each code base enough to do an evaluation and update things. It's been over 2 months now and it's a crappy situation to put our contributors in. On Thu, Nov 5, 2015 at 11:59 AM, Philip Zeyliger <phi...@cloudera.com> wrote: > I think it's always ok to re-release artifacts where nothing's changed. > So, how can you be blocked on another language's implementation if you > simply change the version number and re-release? > > -- Philip > > On Thu, Nov 5, 2015 at 9:43 AM Ryan Blue <b...@cloudera.com> wrote: > >> Phil or Sam, any ideas about how to keep release management simple, but >> be able to avoid blocking specific languages on under-maintained ones? >> >> Also, looking at the release history we've had 3 releases in the last 2 >> years, and that's being generous to include 1.7.5 that was released in >> August 2013. I don't think more release overhead would be that big of a >> problem, and would be well worth keeping the languages that are well >> maintained released and up-to-date. >> >> rb >> >> On 10/30/2015 09:37 AM, Ryan Blue wrote: >> > I think Sean is right that we could continue to release several at once. >> > We would almost certainly continue this practice for several languages >> > that are mostly unmaintained (like perl and php). I also expect each >> > language's release cadence to reflect the activity in that language, >> > which I think is very important to maintain. >> > >> > I also don't want to underestimate the drawback of having a single >> > version for multiple implementations. We can't use semantic verisoning >> > for any of the implementations. If we bump the minor version (!) because >> > of a breaking change in Java, but aren't making breaking changes to C, >> > this is confusing to users. >> > >> > If we don't separate release vehicles, how can we improve version >> > conventions? >> > >> > And how do we ensure timely releases that aren't blocked by other >> > implementations? This affects how attractive this project is to new >> > contributors. If the releases are seldom and contributions aren't >> > available for months at a time, I think we have a problem. >> > >> > rb >> > >> > On 10/29/2015 04:51 PM, Philip Zeyliger wrote: >> >> -0. >> >> >> >> If you divide the world into N releases, you'll end up having to do >> >> release >> >> management N times. I think this will make doing releases that much >> more >> >> complicated, time-consuming, and error-prone. >> >> >> >> Note that you could separate release trains while remaining in a single >> >> repo. I'd certainly prefer that than separating into many smaller >> repos. >> >> >> >> -- Philip >> >> >> >> On Thu, Oct 29, 2015 at 11:31 AM Ryan Blue <b...@cloudera.com> wrote: >> >> >> >>> On 10/29/2015 11:28 AM, Sean Busbey wrote: >> >>>> On Oct 29, 2015 1:19 PM, "Ryan Blue" <b...@cloudera.com> wrote: >> >>>> >> >>>> Where would the language interop tests live if we don't break them >> out? >> >>>> >> >>>> (We already have interop tests, in case that was lost in my original >> >>> email.) >> >>> >> >>> We could either keep them where they are or add a separate repo. >> Running >> >>> them with a release candidate would have to be part of the release >> >>> checks. >> >>> >> >>> rb >> >>> >> >>> >> >>> -- >> >>> Ryan Blue >> >>> Software Engineer >> >>> Cloudera, Inc. >> >>> >> >> >> > >> > >> >> >> -- >> Ryan Blue >> Software Engineer >> Cloudera, Inc. >> -- Sean
