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 is very important to maintain.
I also don't want to underestimate the drawback of having a single
version for multiple implementations. We can't use semantic verisoning
for any of the implementations. If we bump the minor version (!) because
of a breaking change in Java, but aren't making breaking changes to C,
this is confusing to users.
If we don't separate release vehicles, how can we improve version
conventions?
And how do we ensure timely releases that aren't blocked by other
implementations? This affects how attractive this project is to new
contributors. If the releases are seldom and contributions aren't
available for months at a time, I think we have a problem.
rb
On 10/29/2015 04: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
complicated, time-consuming, and error-prone.
Note that you could separate release trains while remaining in a single
repo. I'd certainly prefer that than separating into many smaller repos.
-- Philip
On Thu, Oct 29, 2015 at 11:31 AM Ryan Blue <b...@cloudera.com> wrote:
On 10/29/2015 11:28 AM, Sean Busbey wrote:
On Oct 29, 2015 1:19 PM, "Ryan Blue" <b...@cloudera.com> 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 separate repo. Running
them with a release candidate would have to be part of the release checks.
rb
--
Ryan Blue
Software Engineer
Cloudera, Inc.
--
Ryan Blue
Software Engineer
Cloudera, Inc.
