Subject: Re: [boost] Deprecation Policy
From: John Maddock (jz.maddock_at_[hidden])
Date: 2015-05-17 05:00:35
> However, there is no easy way of telling which libraries are active and which
> are unmaintained. Do I invest time in learning and using a library that is
> unmaintained, or do I adapt to a newer library that is close enough to be
> useful and more likely to be updated with time?
That's a good point, to a first approximation you could look to see when
the last commit to master was (not very user friendly of course), I
wonder if that information could be automated? Or would it be swamped
by admin changes that aren't "real" releases?
In fact the more I think about this, the harder it is to tell, I bet
there are many libraries that are mature enough that they get little or
no maintenance - and frankly don't really need it. They worked fine
yesterday, they'll work fine tomorrow. C++11/14/17 isn't going to
change that. Perhaps in some cases move-aware constructors would be a
useful addition, but that may be all.
You could look at Trac to see if there are large numbers of open issues
- but you know what, old libraries accumulate "unfixable cruft". It
doesn't necessarily make them broken/unmaintained/obsolete. Speaking
only for myself, I generally prefer to leave these open rather than
gratuitously close as "won't fix", even though they will *probably*
never be fixed.
Maybe we need some kind of survey, say 2 libraries a week, skip any that
are obviously maintained and then ask the questions:
* Is the maintainer still around?
* Does it matter - is it accumulating issues?
* Does anything need doing to bring it into C++11/14 land?
* Has it been obsoleted - which is to say, does it make sense to use
this in new code?
I'll finish by pointing out one lib that fails on the last question -
call_traits - in fact I might go off and submit a documentation PR now...
Thinking out loud yours, John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk