On Fri, Jan 11, 2019 at 10:26 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 1/11/19 6:21 PM, Robert Ramey via Boost wrote:
On 1/11/19 7:16 AM, Andrey Semashev via Boost wrote: \
To illustrate, just the other day I had to track down a change in Boost.Filesystem so that I could tell a user when a bug appeared in the code and when it was fixed. I was able to do that, both in terms of Boost realeases and commits with their respective commit messages and dates, because I had a fine grained history with tags. I was able to track down the particular PRs, if I had to. I think, this is an important feature of the detailed git history.
Right - but couldn't you have done that with the develop History?
No, because release tags are applied to the commits in master that are used to ship a Boost release.
Actually, yes, since if you do what I said before and ensure all merges from develop to master are fast-forwards, then the tag applies to a hash which exists in master and develop. The main purpose of having master and develop is that the boost project does not use separate release branches per release, just master. Robert, I see your point, in that most other projects have one train going forward (master) and tags identify releases, and release branches can be used to make releases. Release branches actually would be inherently more stable than asking 130 repositories to stop merging to master, as evidenced by the 1.69.0 release efforts by @Marshall Clow <mclow.lists@gmail.com>. One way we could think about addressing it is to have all PRs go into master, and when we're ready to cut a release, we cut a branch in every repository with the same name, i.e. "release/boost-1.70.0". The release gets done there. Changes get merged back to master. All the while, progress on master can continue. If you need to cherry-pick something into 1.70.0, you do so into the release branch in your repo. Someone has to update the release branch in the super-project too. My guess is some tooling and automation would need to change. I'm okay either way really. I've learned how to use develop and master effectively, but if we switched to just having master and used release branches, that would be more in line with what everyone else does. - Jim