On Dec 7, 2013, at 2:59 PM, "Niall Douglas"
On 6 Dec 2013 at 21:05, Rob Stewart wrote:
The traditional solution is forking of course, so those interested enough fork a library and take it in new directions. Boost is particularly fork unfriendly however - I don't believe anyone has EVER seriously suggested forking any non-trivial chunk of Boost.
Signals2 is an excellent example of just such a thing. We also have cases like Lambda vs. Phoenix.
That's evolution of a component, not forking which would involve multiple libraries being taken in a new direction together.
You previously used the phrase, "those interested enough fork a library", but when I challenge your point, you decide that forking requires many libraries taken elsewhere?
I'll copy and paste from http://en.wikipedia.org/wiki/Fork_(software_development):
"The term often implies not merely a development branch, but a split in the developer community, a form of schism"
That fits my example just fine. A second person thought Signals would be better if modified. The original maintainer didn't want to change it. Thus, a fork of Signals was created and we now have Signals2 alongside (the now-deprecated, IIRC) Signals.
Forking isn't usually about software, it's about differences in the philosophy behind the software.
Yep [snip]
Does this improve your understanding?
Thanks for all of that, but my "understanding" comment was WRT your "significant patches" commentary. (It's probably not productive to revisit that anyway.) ___ Rob (Sent from my portable computation engine)