[boost] [iterator][range] Synchronization on 'master'

Subject: [boost] [iterator][range] Synchronization on 'master'
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-10-16 00:50:42

I have pushed a number of changes to iterator from 'develop' to 'master' 
for the next release.

A series of these changes on 'develop', by Marcel Raad, is an attempt to 
remove from 'iterator' the use of the deprecated headers 
'boost/iterator.hpp' and 'boost/detail/iterator.hpp' in favor of using 
'std::iterator' directly instead of 'boost::iterator' and 
'std::iterator_traits' and 'std::distance' directly instead of 
'boost::detail::iterator_traits' and 'boost::detail::distance'. 
Essentially these changes mean that any other library using 'iterator' 
classes would fail if they attempted to refer to 'boost::iterator', 
'boost::detail::iterator_traits', or 'boost::detail::distance'.

After I had pushed these changes to 'master' I noticed that it broke 
'range' on 'master' and reverted these specific pushed commits on 
iterator 'master'.

On 'develop' the 'range' library ( and possibly other libraries using 
'iterator' ) had been changed so that it correctly used the 
'std::iterator' terminology rather than the deprecated 'boost::iterator' 
terminology.

If we are going to make this change to 'iterator' on 'master' it needs 
to be co-ordinated with the same set of changes for other libraries 
which now work with these changes on 'develop'. I noticed quite a few 
changes for 'range' on 'develop' which have not been pushed to 'master' 
for the upcoming release. I will assume that the maintainer of 'range' 
will want to push these changes to 'master' for the upcoming release so 
this is a heads up that the changes ( actually the last 'develop' commit 
for 'range' ) need to be co-ordinated with 'iterator' if it is done. 
Similarly if any other library depending on 'iterator' needs these 
changes on 'master' it needs to be co-ordinated with 'iterator'. I will 
NOT be re-pushing these changes on 'iterator' until this co-ordination 
is in place as I do not want to break 'master' in the interim.

I am also fine with waiting until after this upcoming release to re-push 
these 'iterator' change to 'master' if that is what is desired by 
others, but any library currently depending on these changes in 
'develop' must be aware of what the decision end up to be.