Re: [boost] Updated Development and Release Practices for 1.35.0

From: Kim Barrett (kab_at_[hidden])
Date: 2007-09-04 12:53:20

At 12:59 AM +0400 9/2/07, Vladimir Prus wrote:
>  2. Say Boost 1.35 is released. Week later, a big source-incompatible
>  change to some library is merged to release-ready tree. Week later, a serious
>  bug is found in another library. Is there a place where that bug can be
>  fixed? Release-ready tree already has source-incompatible change to other
>  library? In other words -- from which tree is 1.35.1 going to be released?

Being a user of boost, I would suggest the answers be

a. The bug fix should be made to the release-ready branch, assuming it
satisfies the processes for doing so. Since the bug is described as
serious, the relevant library author has a pretty strong incentive for
getting the bug fix through the release submission process.

b. By default, there is no 1.35.1. This might be considered
contentious by some, so I will give some arguments in support of that
position.

Boost is an open source project. If a user needs a bug fix back ported
to an earlier version (even the latest release), that user is free to
do it themselves, or convince someone else to do it for them, possibly
by hire. If there are enough users for a particular release wanting
bug fixes back ported, they could even band together and amortize the
cost of "professional" support. The author of the library containing
the bug might choose to do that backport and make it available as a
branch that users can merge from, but I don't think that should be a
requirement.

Who would decide what bug fixes go into a 1.35.1,2,3,... release?
Different users may have different needs there. One user's show
stopper bug might be in another user's "too risky" category.

Boost is an all volunteer effort. It is producing stuff that is
clearly useful to a lot of folks, and of very high quality. I think
this volunteer effort should remain focused on that library
development, and not get bogged down in dealing with more
configuration management issues. Keep moving toward future
improvements, and don't worry to much about past releases.