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 15:05:47

On Monday 09 December 2013 19:56:10 Alexander Lamaison wrote:
> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
> > On Monday 09 December 2013 19:29:59 Alexander Lamaison wrote:
> >> 
> >> However, I think the discussion was about a commit already merged to the
> >> submodule's master branch, so gc won't touch it.
> > 
> > Not necessarily. In my example a boost release (i.e. a tagged commit to
> > the
> > superproject's master) references a commit in a submodule branch that is
> > neither develop nor master. That branch may never be merged to develop or
> > master.
> 
> You mean a special branch quickly made to revert a specific thing before
> a superproject release but not part of the submodule's mainline
> development (i.e. develop)? 

Yes.

> Surely those commits would be merged into
> the submodule master? After all, they form part of a release, both for
> the submodule and the superproject.

It didn't look like that from what Peter was suggesting. I'll re-post his 
example:

<quote>
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.
</quote>

I don't see why such a branch would ever be merged to the main library 
branches (develop or master), unless the maintainer decides to drop the new 
features permanently.