On 11/16/2015 08:10 AM, Sam Groth wrote:
So I have developed for a similar scenario where we had APIs in 3 different
languages that needed to be kept in sync. The releases were split, and we only
had some high level tests to verify compatibility and therefore had to be very
careful what change
So I have developed for a similar scenario where we had APIs in 3 different
languages that needed to be kept in sync. The releases were split, and we only
had some high level tests to verify compatibility and therefore had to be very
careful what changes we made to avoid failures across many dif
Hi,
First of all a +1 from me to move to git.
Regarding the "how many parts and the release cycle";
In general I'm in the "release often" camp.
Yet I understand the needless confusion if a certain language has not
changed.
How about this idea:
We create a separate project (avro-spec) with the
My responses are inline.
rb
On 11/06/2015 07:32 AM, Tom White 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
th
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 inc
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 rathe
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
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 month
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 wrote:
> Phil or Sam, any ideas about how to keep re
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 2
+1
Some thoughts:
* As people said, we need some cross language test. We can look a practices
used for browsers supporting HTML features, MPEG benchmarks and other
systems. Maybe a test system that gets the executable/script to run and
runs regression tests.
* IMO different repos will give more fr
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
+1 for moving to github.
-1 for splitting the release. I agree with Philip that it will be more complex.
Sam
On Thursday, October 29, 2015 6:56 PM, Sean Busbey
wrote:
Why can't we do a single release vote that covers multiple components?
--
Sean
On Oct 29, 2015 6:51 PM, "Philip Z
Why can't we do a single release vote that covers multiple components?
--
Sean
On Oct 29, 2015 6: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
> co
-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 pref
On 10/29/2015 11:28 AM, Sean Busbey wrote:
On Oct 29, 2015 1:19 PM, "Ryan Blue" 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 separa
On Oct 29, 2015 1:19 PM, "Ryan Blue" wrote:
>
> 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.
>
Where would the language i
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
specificall
18 matches
Mail list logo
