Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-21 16:40:25

> I have no problem with any of that.  However, I would like you to
> acknowledge that I *did* in fact address what you wrote, whether or
not
> it was what you wanted to hear.

I acknowledge that you addressed what I wrote.

> I'm not sure how.  Would the "new" code that results from reviews have
> more immediate relevance to you than it does now, in such a scheme?

Yes - that's the whole point!  People are not afraid to beta test when
they 
know the code is beta/pre-release.  People will be more likely to review
code and
participate if they know they can use it in the near-term future.
People 
who save themselves the effort of having to invent their own (probably
inferior) 
version of a library from scratch will also be more likely tolerate
changes
in the early stages.  At the end of the day, most of our users are
library users,
not library writers.  They just want to get their app up and running.  

Increasing your pre-release user and test base can only make the library
better 
and applicable to more domains.  One of the best things for me when
working in
library development was learning how people use my libraries in
scenarios 
I haven't even thought about.  Also, more participation early in the
development 
process will give the user base a stronger sense of ownership and hence
more 
desire to be involved.

I can't tell you how often people here ask for the new libraries, only
to
be shot down because they are only available from release X onwards,
where
X > where we are now.  And when I say people ask for the new libraries,
I do 
really mean ALMOST EVERY SINGLE library that came in since 1.33.1.  

> >> > However, it seems that once a library is accepted, the maintainer
> is
> >> > pretty much free to do what they please.
> >>
> >> Yes.
> >
> > I hope behind this simple "Yes" there are alarm bells going off.
> 
> Not really.  I understand the risks and tradeoffs of that arrangement,
> and I think Boost made the right choices there.  IMO what's needed is
> more structure to support the maintainer in making good decisions.

But you also need the maintainer to actively engage the system when
deciding to make drastic changes.  In the Boost.Range case, it wasn't 
the failure of the boost.devel mailing list.  The changes seem to have
been made without any communication whatsoever.

> I know at least one instance where breaking changes were discussed
> (handling of NTBS's):
> http://www.nabble.com/-Range--Expected-complexity-constraints-
> tt4279749.html#a4279749

And that's the right thing to do.  However, I can't find any references
to 
indicate that the behavior of ranges is about to change in 1.35.

> Yes.  And as as I said, such policies often are used for *all*
> dependencies because people have been burnt by *something* that may or
> may not have been Boost in the past.

Sure - but most other libraries we use are not the basic building blocks
of
most C++ applications and our entire software stack!  Almost every C++
app will have use for things such as Boost.SharedPtr and Boost.Iterators

but they don't all need e.g. a rule based engine.  As such, boost tends 
to be a global dependency while other libraries are much more localized.

Breaking and backing out a single application because of a broken
dependency is 
not a big deal.  Backing out and rebuilding all of the applications in
the firm
is a big deal.

> <snaps head around> What proposal?

I don't know if you're just playing with words here or not.  It wasn't a
"proposal" in the sense of a written document which is suitable for
submission
to the C++ committee.  I was referring to the idea of the different
release cycles
for the "core" and "new" components.

Tom