Re: [boost] Deprecation Policy

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.