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