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

Subject: Re: [boost] A proposal for superproject structure and testing
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2013-12-09 15:36:46

Andrey Semashev <andrey.semashev_at_[hidden]> writes:

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

The 'master' branch means 'this was a release'.  It doesn't mean 'this
was an ideal version of the library'.  Eventually the maintainer would
need to re-try the feature, at which point it would be merged from
'develop' to 'master' and take over from the quickly-fixed version.

If the submodule uses the git-flow model, the quick-fix would be done on
the 'hotfix' branch.  Then that would be merged into 'master' and form
part of the superproject's master.  Later the 'hotfix' branch should be
merged back into 'develop' and the feature would have to be re-done on
top of it.  If the submodule is using some other branching model, they
don't have to merge the hotfix back in but it should still appear on
'master'.

Alex

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)