From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-02 23:54:19
----- Original Message -----
From: "Braden McDaniel" <braden_at_[hidden]>
Sent: Saturday, March 02, 2002 11:30 PM
Subject: Re: Installing Boost (WAS: Re: [boost] Re: Why Jam?)
> On Fri, 2002-03-01 at 15:18, David Abrahams wrote:
> > ----- Original Message -----
> > From: "braden_mcdaniel" <braden_at_[hidden]>
> > > > That's not a very smooth solution for those who need to test
> > > > multiple versions.
> > >
> > > Such persons are the minority. It is better to make their lives a
> > > little more difficult than to make the lives of everyone else much
> > > more difficult.
> > >
> > > What other libraries use a scheme like Rene suggested?
> > Python does something similar.
> The strategy is particularly useful when it is anticipated that users
> may need to have multiple versions of binary packages concurrently
> > > These issues with deployment aren't new, and they certainly aren't
> > > unique to Boost. Why are novel solutions being proposed?
> > Why do you say "novel"? It's not as though these ideals are local
> > inventions. Rene's suggestion is taken from other *nix libraries and
> > we've seen where versioning counts.
> Come now, there are *plenty* of projects where "versioning counts"
> don't take such extreme measures.
Awfully combative, aren't you? I didn't say the idea came from looking
at every single project where versioning counts and noticing that they
all do it this way. All I suggested was that it's not a novel idea;
there is precedent. Instead of answering my question about why you're
calling it "novel", you're now calling it "extreme". So now I have two
questions: why does Rene's idea seem "novel" and "extreme" to you? There
certainly are a number of open-source projects that work this way.
> In general, projects have a "development mode" where compatibility is
> not guaranteed from release to release. Eventually the feature set is
> resolved, things stabilize, and ultimately a release is made against
> which binary compatibility is guaranteed for future releases in that
> "product line". The project may go back into development mode; and at
> that time, if it is appropriate to accommodate concurrent
> of the old product and the new product, such strategies as
> the version number into the product identifier may be appropriate.
> But Boost is in that initial development mode. There has never been a
> product line established for which there has been any kind of
> of "maintenance releases". Thus the requirement to segregate Boost's
> releases as described is questionable.
I don't think it's a requirement, just an idea which some happen to find
appealing. It seems potentially useful and relatively non-intrusive. Is
there a downside?
> Furthermore, incorporating version numbers into the directory
> makes sense only when those numbers can be used to distinguish
> compatibility. But Boost has lots of parts--many of them distinct--and
> users may only use a few of them. For a given library within Boost,
> overall Boost version number is not usefully informative as to the
> of compatibility with a previous release.
Not by iteself, but it does tell you something definite about the state
of the library.
> I think incorporating the Boost version number into the directory
> structure complicates deployment, and accomplishes very little.
I know it will make my life a little more convenient. How does it
complicate deployment? Is this really worth arguing over?
> > > > Having a version number under a common prefix really
> > > > simplifies configuration: it means you don't need to explicitly
> > > specify an
> > > > installation directory for each version you want to test
> > >
> > > Testing against multiple versions of Boost is definitely an edge
> > Since it appears we can make everyone happy using symbolic links, do
> > really have to choose?
> I think it is appropriate to question whether the edge case you
> *really* warrants complicating deployment.
I guess the answer depends on whether it really does complicate
deployment, and by how much.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk