GitFlow master is not updated

[Frank Dellaert]

Apparently the master branch does not have our releases. See http://nvie.com/posts/a-successful-git-branching-model/

[Frank Dellaert]

There are also no tags after 2.3.1 :-(

[Chris Beall]

Issue #11 was marked as a duplicate of this issue.

[Chris Beall]

I can probably do that easily for releases since 8/15/2013, which is where master currently ends. To do this for releases predating 8/15/2013, I'd probably have to delete master, and then re-construct for each release from the beginning which would be tedious.

We have release/*.*.* branches. I'll tag those. Those should never be merged back into develop, as may be done in git-flow. We've been yanking stuff out of GTSAM in those branches to prepare each release.

[Frank Dellaert]

Yes, it would be good to merge to master from the release branches. That's the gitflow idea.

[Chris Beall]

I think you didn't notice my last comment was about develop. That part of git-flow we should continue to ignore. It was unrelated to your request, but I wanted to point that out.

• release->master, good.
• release->develop, bad.

[Frank Dellaert]

Yes, release->master, good, so let's do it :-)

[Chris Beall]

I think it's settled. For the record, I used git merge -X theirs release/3.2.1 to override conflicts. If you think it looks good, I can delete the release branches. They're no longer needed, with master keeping the record.

[Frank Dellaert]

Awesome

What conflicts? Should we expect conflicts?

[Chris Beall]

In general, no, but can happen when files were deleted in a release branch, and reappear in a following release branch because it was never actually deleted from develop. For example, testBetweenFactor.cpp was deleted from release/2.3.1, but remained in develop and therefore made it into release/2.4.0.

See: https://bitbucket.org/gtborg/gtsam/commits/69f2dcce608ff87f313bd6a0e1bdb9c704a41cf3

[Frank Dellaert]

Ah, yes. Great !