Re: Installing Boost (WAS: Re: [boost] Re: Why Jam?)

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-02 23:54:19

----- Original Message -----
From: "Braden McDaniel" <braden_at_[hidden]>
To: <boost_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
against
> > > > 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
> installed.
>
> > > 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
tools
> > we've seen where versioning counts.
>
> Come now, there are *plenty* of projects where "versioning counts"
that
> 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
installations
> of the old product and the new product, such strategies as
incorporating
> 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
guarantee
> 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
structure
> 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,
the
> overall Boost version number is not usefully informative as to the
state
> 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
against.
> > >
> > > Testing against multiple versions of Boost is definitely an edge
case.
> >
> > Since it appears we can make everyone happy using symbolic links, do
we
> > really have to choose?
>
> I think it is appropriate to question whether the edge case you
describe
> *really* warrants complicating deployment.

I guess the answer depends on whether it really does complicate
deployment, and by how much.

-Dave