|
Boost : |
Subject: Re: [boost] Deprecation Policy
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-16 18:43:56
On May 16, 2015 6:31 PM, "Rob Stewart" <rob.stewart_at_[hidden]> wrote:
>
> On May 16, 2015 4:26:29 PM CDT, Stefan Seefeld <stefan_at_[hidden]>
wrote:
> > On May 16, 2015 2:29 PM, "Rob Stewart" <rob.stewart_at_[hidden]>
> > wrote:
> > >
> > > Some Boost libraries are unmaintained, some are under-maintained,
> > and
> > others have been replaced by newer libraries or by the Standard
> > Library.
> > Boost needs to decide whether to deprecate such libraries, and if so,
> > how
> > and when to do it.
> > >
> > > Please consider my initial thoughts below and provide ideas on such
> > a
> > policy. I will try to capture your ideas and create a policy statement
> > for
> > later review.
> >
> > I think the entire question becomes moot if individual libraries start
> > following their own release schedule. Being maintained then means
> > having
> > regular releases (and thus over time it becomes obvious whether a
> > library
> > is maintained or not).
>
> The goal is to offer both for the foreseeable future. (For example, the
way my company handles Boost, the monolithic release is more appropriate.)
I imagine it's entirety possible to produce a "boost release" (or "distro"
to use a term Niall suggested) consisting of all the latest releases of
individual boost libraries.
You might argue that it's hard to guarantee compatibility among them. But
that has been a problem Boost has been plagued with forever: no two boost
releases have ever given any guaranty of compatibility. So here again, a
little change in policy would very much benefit boost users.
Stefan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk