Subject: Re: [boost] Release managers: Boost.Thread breaking changes in 1.53
From: Roland Bock (rbock_at_[hidden])
Date: 2012-12-31 02:44:25
On 2012-12-30 21:42, Dave Abrahams wrote:
> on Sun Dec 30 2012, Olaf van der Spek <ml-AT-vdspek.org> wrote:
> If I move from boost::thread to std::thread then yes, I'm expecting
> some costs moving.
> But merely 'upgrading' Boost, which might not require any action from
> the developer himself, should not come with such costs.
> There are no absolutes in this area. Upgrades of Boost are allowed to
> break code. In general we try to avoid it, but sometimes progress is
> more important than backward compatibility. When to break code, how
> much warning users get, what their alternatives are, etc., are judgement
> calls we leave to library maintainers.
I think the main problem is expectation management:
Since more than 50 releases there has been one minor release number
change (1.x -> 1.(x+1)) after the other. No distinction. It would be
much easier (for users) if there were rules about what kind of library
changes are to be expected for what kind of release number changes.
Micro releases x.y.z -> x.y.(z+1):
- Bug fixes
Minor release x.y.z -> x.(y+1).0:
- Bug fixes
- Performance enhancements
- backward compatible extensions
Major release x.y.z -> (x+1).0.0:
- all of the above
- breaking changes
Major releases should be rare, of course, but if they occur, library
users would know that they have to expect breaking changes.
Maybe this can be achieved with distributed boost?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk