Consensus is a big word for this case.
I am not really convinced this will get us to a better state for the reasons
already exposed before. In my opinion we are having a BIG case of
wishful thinking.
We had a really hard time to put together a new release for 1.9.0 and one of the
reasons was the
It sounds like there is consensus around separating the languages into
separate releases and possibly projects. Should we consider a separate
discuss & vote thread for that alone? I don't think there's a need for an
improvement proposal there.
On Sun, May 3, 2020 at 7:47 AM Andy Le wrote:
> +1
+1 the project structure and more documentation.
I'm really impressed with the way Vertx documentation organized.
Finally, so what should we do? IMHO, we should:
- Clear about the organization
- Brainstorming what to do in a plan
- Publicly show the plan & call for contributions
I'm a newcomer
Yes, I'd love to see the AEPs being revived. This would enable it to make
more structural/fundamental changes, such as the one mentioned above. This
also enables others to have a complete overview of changes and the impact.
I also agree with Michael when it comes to the project structure. Maybe
I am all for expanding the core types… the current logical type shortcuts in
the IDL lang will make this a bit more interesting to implement (I think they
confuse more than they help)…
Regarding ID based field tracking, I am not sure I understand what problem does
it solve, and there might be
Definitely in favor of the AEPs.
I have mixed feelings about the notion of a single language binding. These
types of packages are commonplace enough in Python, but installing a Python
package that requires a build time clib is often troublesome, and I'm often
grateful to find a pure Python
+1 for the suggestion of Ismaël. A sample implementation can be found here:
https://github.com/flavray/avro-rs. Gonna have a detail look at it :D
*One more radical idea I would like is to try is to unify a bit the
implementations probably having a robust low level one in one systems
language
+1 for removing code that isn't maintained. We can still bring it back if
anyone is interested, but I like the idea of retiring it so that users get
a clear idea of its state (unmaintained) and so it doesn't slow down
development (releases blocked by code rot). I support separate versioning
and
Huge +1 to recover the Avro Enhancement Proposals (AEP)
The experimental features Ryan mentioned definitely merit(ed) to be
part of it, and in particular the procedure to decide when they will
become ‘stable’ or default, for example for fastread. Also other
proposals/discussions like the split
Hello!
You bring up some good points -- I'm glad Avro is so widely used, but
it does make me nervous to see any changes that might break other
projects, or change any behaviour.
Currently, we've talked about managing developer expectations with
semantic versioning (especially with the necessary
Hi Andy,
Thanks for reaching out. Sorry for not being so active in the community
lately.
Since Avro 1.8.2 there has been some activity on the repository again,
fixing stuff like security issues and migrating to later versions of Java.
Avro has been around for 10 years now, and I would like to
11 matches
Mail list logo
