Re: [boost] Release managers: Boost.Thread breaking changes in 1.53

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.

For example:

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?

Regards,

Roland