On Aug 26, 2014, at 19:08 , Marvin Humphrey <[email protected]> wrote:
> On Tue, Aug 26, 2014 at 3:15 AM, Nick Wellnhofer <[email protected]> wrote: > >> There are some classes like LockFreeRegistry that shouldn't be exposed, >> maybe by marking them private. But we can deal with that later. > > Hmm. I don't understand this approach to publishing an API. What I meant is that we can first write the code that generates the docs, then think about what parts of the API we want to make public. > Clownfish is likely to remain in flux for a while yet -- but if we expose a > public API, we're making backwards compatibility promises which either > constrain our ability to evolve the library, or if we break them, try the > patience of our users. > > Forestalling the publication of an immature API and finishing Clownfish's > fundamental design is important enough to me that I've put other projects on > hold (including the Apache release policy clarification initiative and the > Lucy Book Club). Disappointing my collaborators in those other projects was > painful, but it was the right move -- because you've invested so much, Nick, > and because I believe that the Clownfish "symbiotic" approach is important in > this era of siloed language ecosystems. > > So please help me to understand where you want to go. Do you want to freeze > the API? Do you want to simply break compat later? > > My priority would be to write Clownfish bindings for Python and Ruby, and > optionally Go. Once we finish those, I think we will have understood enough > of the challenges of writing a symbiotic object system that we can make nearly > optimal engineering compromises. My plan is to publish an immature API and break compatibility when we release new versions of Clownfish. In my opinion, Clownfish 0.4.0 is a usable product. With Lucy, we have a mature and complex downstream project after all. I primarily want to attract new developers and I don’t think this will work if we keep Clownfish as a black-box implementation detail of Lucy. Do you really want to complete the development of Python and Ruby bindings first before telling people that they can start using Clownfish? At the current pace of development, this might take a couple of years. What’s so bad about releasing new versions that break compatibility? Potential users should be made aware that Clownfish is in flux, but they can continue to use any old version they like. I don’t think maintaining old releases will be much work, so what do we have to lose? We could gain much more from any bit of additional visibility. Nick
