reef-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Weimer <mar...@weimo.de>
Subject Re: "The overhead of reviewing and testing"
Date Wed, 27 Jan 2016 19:08:23 GMT
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.

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?

Markus

Mime
View raw message