Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Stephen Nuchia (snuchia_at_[hidden])
Date: 2008-11-21 09:27:54

I can address this from the commercial user's point of view.  I have a
long history in open source and am currently working for a
well-established Windows-only ISV.  Boost has its own way of doing
things that is poorly coupled into my environment.  Adapting a new
release of boost into my build scripts to evaluate it is painful and
time-consuming.

I have my own release cycle that has periodic windows for non-emergency
updates of tools and other third-party components.  If your two-week
beta period happens to fall in that interval I'm likely to work with it,
otherwise it's going to be whatever is stable.

We have close to five million lines of our own code, a dozen or so
third-party libraries of all descriptions, tools from several different
vendors, and we test against every Windows version since NT4.  If there
were a well-maintained cookbook for testing the beta against my build
I'd give it some attention.  But it took me a week of pulling my hair
out over the bjam / boost build documents to get it wired into my build
the last time I upgraded.  I'm not looking forward to doing that again,
and my boss has other ideas about how I should spend my time -- up to
the point where we need something from the new release.

Having worked the beta cycle from both sides in the commercial software
world, I can tell you it never works very well.  When well-planned,
well-resourced, and well-executed it can be useful.  But it is seldom as
useful as one might hope or imagine it could be.

As for breaking existing use cases, this will cause us to stay at the
last release that meets our needs until the beginning of a new major
release cycle on our side, unless there's some other feature that
compels us to deal with the breaking change mid-cycle.  We're not using
that much from boost so we'd not even notice many breaking changes but
if one hit a feature we're using widely we would not / could not
consider adopting that release mid-cycle without some serious bug or
similar justification compelling it.

Our products are used in stringently regulated environments for
life-critical purposes.  We aren't permitted to change anything without
a good reason.  The beginning of a major release cycle is the only
window we have for big infrastructure changes.  That's an unusual
constraint but every user will have some unusual constraints on their
resources and/or freedom of action.  Boost competes for that limited
pool of beta-participation time with all the other tool and library
vendors.  Open-source status gives you champions in the development pit
but it doesn't change management's priorities.

-swn