The semantic version conversation is being conflated into here. I'm not a true believer, but I'll simply point out that there is the library version and the IPC protocol and file format version, and those need to be discussed separately. I.e., it's very possible to change the Python API in an incompatible way while retaining the same file formats, and so on.
If we don't have the people interested in maintaining a release for language X, perhaps language X should imply be removed? It can be re-retrieved when it's staffed. I'm +1 on git. I remain -0 on separating things. On Fri, Nov 6, 2015 at 7:32 AM Tom White <t...@cloudera.com> wrote: > I'm not sure that moving to a model where there are releases of individual > components will increase the frequency of releases. There will still need > to be a release manager for each component, and then there's a danger that > the less maintained components will not get released at all. > > I would rather continue to make the release process easier (Docker helps a > lot) so that any committer can do it. We should be able to use the Docker > work to run tests for all components with Jenkins to ensure that trunk is > always in a releasable state. > > Where are we with the licensing issues? If we can get those worked out then > I'd like to make a release (of all components). > > I'm +1 on moving to git. > > Cheers, > Tom > > On Thu, Nov 5, 2015 at 12:45 PM, Ryan Blue <b...@cloudera.com> wrote: > > > It isn't just license problems, either. Releases that include all of the > > languages can be blocked by bugs that need to be fixed in those languages > > that are suggested during release planning. > > > > It is also necessary to make sure the older language implementations > still > > build and pass tests, which can mean, for example, installing php and > > fixing any tests that currently break. Tom's recent work to port the > build > > to docker really helps this situation, but that took patches to > > unmaintained implementations and will still require maintenance. > > > > I also disagree that it's always okay to re-release artifacts. Everything > > is moving toward semantic versioning and I think that Avro should as > well. > > It is confusing to users to have an identical library released with a > > version number that indicates a breaking change (though it appears not to > > be by semver rules). > > > > Each language should adopt a release cadence that works for its > > contributors so that those contributors are able to use their work in > > timely releases. Otherwise, I'm afraid that we will see fewer > contributions > > because of the long release cycle we currently have. > > > > rb > > > > On 11/05/2015 10:09 AM, Sean Busbey wrote: > > > >> 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 > >>> > >> > > > > -- > > Ryan Blue > > Software Engineer > > Cloudera, Inc. > > >
