Re: [boost] Deprecation Policy

Subject: Re: [boost] Deprecation Policy
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-05-17 16:31:51

Le 17/05/15 11:00, John Maddock a écrit :
>
>> 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.

Next follows some reports that could help:
Open Bug count by Component - https://svn.boost.org/trac/boost/report/24
Newest closed ticket by component - 
https://svn.boost.org/trac/boost/report/40
Oldest modified active ticket by component - 
https://svn.boost.org/trac/boost/report/39

As any figures, these are just figures. Common sense is needed.
> Maybe we need some kind of survey, say 2 libraries a week, skip any 
> that are obviously maintained and then ask the questions:
Good idea.
>
> * 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?
>
This report

Newest closed ticket by component - 
https://svn.boost.org/trac/boost/report/40?sort=modified&asc=1&page=1

gives a good hint of libraries that could be unmaintained. A library 
that don't have new fixed issues and that have a lot of them could be a 
candidate that merits to be inspected.

Vicente