Re: [boost] A proposal for superproject structure and testing

Subject: Re: [boost] A proposal for superproject structure and testing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-09 10:12:57

On Monday 09 December 2013 06:57:13 Steven Watanabe wrote:
> AMDG
> 
> On 12/09/2013 06:47 AM, Andrey Semashev wrote:
> > On Monday 09 December 2013 16:32:18 Peter Dimov wrote:
> >> Andrey Semashev wrote:
> >> We're using different meanings of "fix" here. Imagine that the submodule
> >> has the following sequence of commits:
> >> 
> >> - bug fix
> >> - new feature
> >> - bug fix
> >> - more of new feature
> >> - bug fix
> >> 
> >> and the new feature turns out to block the Boost release. Fixing the
> >> problem, in your sense, means fixing the new feature so that it becomes
> >> Boost-release-worthy. This should indeed be done in develop. Fixing the
> >> problem, in my sense, means doing
> >> 
> >> - revert "more of new feature"
> >> - revert "new feature"
> >> 
> >> on a branch.
> >> 
> >> <snip>
> > 
> > You can "revert" the feature by just changing the reference to the commit
> > in the superproject release branch to an earlier commit, before the
> > feature was added to the library master.
> 
> No you can't.  Look at Peter's example again.
> Doing this would also revert the other bug fixes.

Maybe the submodule should be forked then. The superproject would then 
reference the master branch of the fork with the necessary modifications. At 
least, this would make sure that the superproject release will stay valid as 
long as the fork is present. With the branch approach, the branch can be 
deleted, and if I'm not mistaken, the release tag would then reference a non-
existent commit of the branch.