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.
>

Reply via email to