Adding [DISCUSS] to the thread to make it more obvious.
Yes, we could add a cross-language test suite in a separate repo. I
think this is out of scope for this discussion, but we definitely need
to have compat tests.
For format versions, I would say we should move eventually to a
specifically supported version, but there is no need at the moment
because v1 is the only version and I don't think there is talk of a v2
at all yet.
Right now, we use the major version number for format, but this is
incompatible with now-standard semver API versioning. I'd be a fan of
separating this out when we need to add another version, but we don't
really need it until then.
rb
On 10/29/2015 11:06 AM, Sean Busbey wrote:
Presumably this would allow us to make the cross-language tests their
own module that the language ones could then use directly for testing?
How do we track which format versions are supported by given language versions?
On Thu, Oct 29, 2015 at 12:18 PM, Ryan Blue <b...@apache.org> wrote:
Hi everyone,
Right now we keep all of the language implementations in SVN together and
release everything in a single source release, which I think is getting a
little awkward for releases. I'd like to discuss the idea of separating some
of the languages out on their own and moving to Apache git servers instead
of SVN.
The motivation for separating languages out is to allow quicker releases
that aren't blocked on problems in other languages. For example, we recently
found license documentation issues through most of the codebase. That's
currently blocking the global 1.8.0 release until we have time to figure out
how to fix the LICENSE and NOTICE included in each convenience binary
artifact. That, in turn, is blocking downstream projects like parquet-avro
that would like to depend on features in 1.8.0.
We're also seeing an influx of new implementations: Microsoft has pinged the
issue to donate their C# implementation, Miki Tebeka is interested in
merging fastavro, and Matthieu Monsch has kindly offered a fast node-js
implementation as well. These are great for expanding the community and I
want to make sure these new projects aren't blocked when they are used to a
faster release cycle.
I propose we allow implementations to use separate repositories, like
avro-python or avro-java, and to make separate releases. This would allow
some languages to have more agile release cycles and would allow us to
version APIs more effectively, using semver for each language and fixing
format compatibility at version 1.
Thoughts and discussion?
rb
--
Ryan Blue
--
Ryan Blue
Software Engineer
Cloudera, Inc.
