reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Byung-Gon Chun <>
Subject Re: "The overhead of reviewing and testing"
Date Wed, 27 Jan 2016 23:24:23 GMT
On Thu, Jan 28, 2016 at 4:08 AM, Markus Weimer <> wrote:

> On 2016-01-27 10:53, Dongjoon Hyun wrote:
>> Specially, item 4 needed `Deprecation process` due to the change of
>> `public` functions.
> Yes. I believe *that* overhead is what sparked the whole conversation.
> Fortunately, we have production level users even in the current 0.x days.
> At the same time, our code base shows signs of rapid growth, which prompt
> us to do all sorts of cleanup work which sometimes breaks users.
> So far, we've made the promise not to break any `public` API in between
> releases. This creates a constant tension between the cost of maintaining
> this promise and the agility of our development. This is most annoying in
> the case of trivial changes like a mere rename, which can really spiral out
> of control:
>  * in 0.x, introduce the new name, deprecate the old one and document
>    it all. Maintain two sets of tests, one per name. File a JIRA to
>    remove the old code in release 0.x+1, link it all up correctly.
>  * in 0.x+1, remove the old code and tests of it.
> With the current release frequency, the two steps happen with at least a
> month in between them. This makes it very hard for people to muster up the
> motivation and discipline to follow through on those.

The deprecation process is really painful. At the end of the day, we're
discouraging people to pay attention to such code parts. Thanks to Dongjoon
and others who've been taking the painful tasks!

> For the .NET side, we've decided to break this promise in 0.14 as there
> were just too many small, breaking changes to first deprecate and then fix
> in 0.15. Instead, we just collect them as breaking changes for the release
> notes.
> Maybe we need to make that the rule instead of the exception? As in: we
> break APIs in between releases, but document these breakages? Especially
> until a 1.0, that could be an OK thing to do?

I'm fine with the suggestion. What do the clients of REEF in production

For new public APIs, we're using "@Unstable" annotations extensively if the
APIs might change in the future. Breaking @Unstable public APIs should be

It's good to have a release note that describes changes. But this will give
more work to release managers.

Back to the [MINOR] tag. I think this has a value. If we have small code or
comment changes (e.g., fix typos not involving important public APIs or
deprecated methods), we can treat the tag as a signal not to run tests
locally if the CI tests pass. To me, running tests locally is the most
time-consuming part for small changes. Reviewing small changes and merging
them can be quickly done.
The tag is declared by a contributor. The reviewer can check the changes
are actually minor or not in the review process.

> Markus

Byung-Gon Chun

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message