[iterator][range] Old breaking change in develop.
Hi, There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it): https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bda... Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted. Daniel
On Mon, Jun 2, 2014 at 4:34 AM, Daniel James
Hi,
There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it):
https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bda...
Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted.
+1 --Beman
On 06/02/2014 01:34 AM, Daniel James wrote:
Hi,
There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it):
https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bda...
Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted.
What is your rationale for reverting the change? \e
On 2 June 2014 20:15, Eric Niebler
On 06/02/2014 01:34 AM, Daniel James wrote:
Hi,
There's an old breaking change to iterator_facade in iterator's develop branch, which is apparently needed for iterator_range (although it seems to have got by without it):
https://github.com/boostorg/iterator/commit/512298cb5cf4b7ca5e8000f41bb39bda...
Please can someone who cares about it decide if that's something that should be released, and if they think it is, take responsibility for it (documentation, release notes, support, etc.). If not, I think it should be reverted.
What is your rationale for reverting the change?
Unmerged changes cause maintenance problems. There are later changes that need to be merged, and we shouldn't have to mess around with cherry-picking because of some abandoned changeset. If no one cares enough about it to support it then what else can we do with it? Release it with no support, keep it unreleased in develop where it can only cause problems, neither is a good idea. If someone is willing to maintain the library, that's great. If not and it gets reverted, and in the future someone wants to redo the change, they can still do that, it will still be in the version history. Nothing is deleted.
participants (3)
-
Beman Dawes -
Daniel James -
Eric Niebler