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.