My view is that it is good practice to consider breaking an interface should be considered a bug.
Does your view accepts that exceptionally a well documented breaking change with a reasoable deprecated period could not be considered a bug?
Well, if its intentional, it's by definition not a bug - its a feature.
The responses to the posting cited above, indicate to me that there is no consensus to support this view point.
You are right, there was no consensus at all respect to this point.
May be we can reach a consensus in other points that can make Boost more backward compatible if not completly backward compatible.
We don't need a consensus to make progress. I believe that progress can be made by winning more developers to this point of view. It just takes time - lots of time spent just like this.
Do you think that the deprecation of a feature should be considered as a bug? If not how long should a reasonable period be for you?
<snip> ...
Of course it has to happen occasionally. My view is that it happens much more often than necessary. I understand that library author's want to make their works as perfect as possible. It's this exact character flaw that makes us successful at what we do. Buf if libraries want to have their libraries to be successful, they have to understand that they have to build trust with users and they can't do this by leaving them hanging out to dry. I realise that they don't think they're doing this - but they are - and I'm here to point this out.
Yes, I could add an index by author, user, RM. Why not.
Actually, I'm thinking the the a library author face entirely different problems. a library author want's to cover as much ground (compilers, user errors, use cases, etc) as possible. So suggestions like don't break an interface, use things like boost/config, Use Boost.Concepts to help your find mistakes in library usage, etc. are to him. a user want's to get done with as little as trouble and suprises as possible. So suggestions like avoiding "using" are helpful. For users, I'm thinking of suggestions similar to "Effective C++, oriented to boost. Any writing "Effective Boost"? Robert Ramey