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

Andrey Semashev writes:

On Monday 09 December 2013 19:56:10 Alexander Lamaison wrote:

...

Andrey Semashev 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)