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