Re: [Boost-users] [boost] Maintenace Guidelines wiki page

Subject: Re: [Boost-users] [boost] Maintenace Guidelines wiki page
From: Robert Ramey (ramey_at_[hidden])
Date: 2008-11-23 01:39:06

>> 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