on Sun Jan 04 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
David Abrahams wrote:
on Fri Jan 02 2009, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
2. Major changes in library functionality should be reviewed.
Not commenting on #1. As for #2,
a. That has never been Boost's official policy. We can have a debate about it, but that debate has yet to occur and there's certainly no consensus.
That's true. I was just expressing my point of view. To me, a major addition to an accepted library or a major overhaul of its interface is equivalent to a new library submission, and therefore it should undergo a review. Maybe, a lightweight one.
b. I have never seen an example where such a change was conducted with good library evolution practices and it caused major problems.
c. I've seen several examples where undertaking even minor changes without good library evolution practices causes major pain.
I remember a lengthy discussion about a change in Boost.Range recently. Technically, it may not have been a major change in code, and I'm not judging now whether that change improved the library or not. But the fact is that it caused problems for the end users.
Exactly. It was a relatively minor change especially when compared to the Spirit-2 rewrite, which is many orders of magnitude more significant. It was probably /more/ of a problem for users than any major change because it happened relatively quietly without any "this is going to change your world" fanfare.
I'm not sure whether it applies to (b) or (c), because I didn't see any guidelines of good library evolution practice on the web site.
It's true; someone started to write something, but I think the effort has flagged a bit (https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines) Nonetheless, you don't need to have guidelines written down for there to be such a thing as good practice ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com