question/guidence regarding merge to master
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated. Robert Ramey
Hi Robert, On 2019-01-10 9:20 p.m., Robert Ramey via Boost wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
I don't think there is (and should be) a Boost-global rule on how to handle this, though some guidelines might be useful. (There tend to be different camps of people with different preferences, such as the ones preferring clean branches who tend to use `git rebase` a lot versus those who frown upon `rebase` (and history rewrites) as they insist on clear audit trails, especially if code reviews are involved. So rather than opening the door for yet another area of endless debate, I'd simply recognize such styles, and document pros and cons. As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont..., which I find quite helpful. Collecting such notes on our wiki might be useful. -- Stefan ...ich hab' noch einen Koffer in Berlin...
Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:
Hi Robert,
On 2019-01-10 9:20 p.m., Robert Ramey via Boost wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
I don't think there is (and should be) a Boost-global rule on how to handle this, though some guidelines might be useful.
(There tend to be different camps of people with different preferences, such as the ones preferring clean branches who tend to use `git rebase` a lot versus those who frown upon `rebase` (and history rewrites) as they insist on clear audit trails, especially if code reviews are involved. So rather than opening the door for yet another area of endless debate, I'd simply recognize such styles, and document pros and cons.
As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont..., which I find quite helpful. Collecting such notes on our wiki might be useful.
I lately found this very good (and long), educational blog-entry [1] which explains when and how to use `git merge` and `git rebase`. I highly recommend everyone using Git reads it and adopts it. HTH, Deniz [1] https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c...
On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost <boost@lists.boost.org> wrote:
Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:
As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont..., which I find quite helpful. Collecting such notes on our wiki might be useful.
I lately found this very good (and long), educational blog-entry [1] which explains when and how to use `git merge` and `git rebase`.
I highly recommend everyone using Git reads it and adopts it.
[1] https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c...
"I’ll cherry-pick every commit one by one"? "You fools, you have no idea what you are doing!" - could have the mighty Raymond Chen call [1] Please, let's not drift this discussion into the religious battle of merge vs rebase and alike. We (Boost) are already heavy-weight sinners sticking to the "GitFlow considered harmful" [2] [1] https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 [2] https://www.endoflineblog.com/gitflow-considered-harmful Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 11 January 2019 15:27 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: Re: [boost] question/guidence regarding merge to master
On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost <boost@lists.boost.org> wrote:
Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:
As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont...
contributors-with-write-access,
which I find quite helpful. Collecting such notes on our wiki might be useful.
I lately found this very good (and long), educational blog-entry [1] which explains when and how to use `git merge` and `git rebase`.
I highly recommend everyone using Git reads it and adopts it.
[1] https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c...
"I’ll cherry-pick every commit one by one"?
"You fools, you have no idea what you are doing!" - could have the mighty Raymond Chen call [1]
Please, let's not drift this discussion into the religious battle of merge vs rebase and alike.
We (Boost) are already heavy-weight sinners sticking to the "GitFlow considered harmful" [2]
[1] https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 [2] https://www.endoflineblog.com/gitflow-considered-harmful
But neither of these articles mention using sub-projects, a key difference with Boost's git structure. I feel that I'd like to get 'my' branch straight before trying to cope with the effect of changes in other branches (unless that was what I really was trying to resolve). Looking at the test matrix shows far more platforms and compilers than I can test locally. So is that what develop is for? Maybe others feel the same of about 'their' branches. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Fri, 11 Jan 2019 at 17:11, Paul A. Bristow via Boost <boost@lists.boost.org> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot via Boost Sent: 11 January 2019 15:27 To: boost@lists.boost.org Cc: Mateusz Loskot Subject: Re: [boost] question/guidence regarding merge to master
On Fri, 11 Jan 2019 at 15:41, Deniz Bahadir via Boost <boost@lists.boost.org> wrote:
Am 11.01.19 um 03:40 schrieb Stefan Seefeld via Boost:
As to guidelines, there are a few useful documents online, such as https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/cont...
contributors-with-write-access,
which I find quite helpful. Collecting such notes on our wiki might be useful.
I lately found this very good (and long), educational blog-entry [1] which explains when and how to use `git merge` and `git rebase`.
I highly recommend everyone using Git reads it and adopts it.
[1] https://medium.com/@porteneuve/getting-solid-at-git-rebase-vs-merge-4fa1a48c...
"I’ll cherry-pick every commit one by one"?
"You fools, you have no idea what you are doing!" - could have the mighty Raymond Chen call [1]
Please, let's not drift this discussion into the religious battle of merge vs rebase and alike.
We (Boost) are already heavy-weight sinners sticking to the "GitFlow considered harmful" [2]
[1] https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215 [2] https://www.endoflineblog.com/gitflow-considered-harmful
But neither of these articles mention using sub-projects, a key difference with Boost's git structure.
Indeed! My point was to illustrate, perhaps unnecessarily, that there are too many Git-basd religions. People suggesting X way superior to Y way often forget those small details that make huge difference. Just to point out a few, perhaps unnecessarily again: e.g. inward vs outward direction, https://blogs.msdn.microsoft.com/oldnewthing/20180312-00/?p=98215#comment-13... or the fact that most of Git workflows discussed out there assume Web app development where `master` is always shippable and there are no long-lived release branches that need to be maintained, etc.
I feel that I'd like to get 'my' branch straight before trying to cope with the effect of changes in other branches (unless that was what I really was trying to resolve).
Looking at the test matrix shows far more platforms and compilers than I can test locally.
So is that what develop is for?
Despite GitFlow has been receiving bad PR latel, it seems to be serving Boost super-project quite well for the reason you pointed earlier: integration of multiple individual project does require an extra area for pre-production staging. Any other, simplier workflow may fail. What is maintainer's local workflow for integrating changes into library's master or develop is not a concern of Boost maintenance. A library is a submodule after all, with separate history. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Robert Ramey wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
My guideline is: - work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master That is, develop is not a place for experimentation (or, ironically stated, develop is not for development). The squashing, if needed, happens on the merge from the experimental feature branch into develop, not on the merge from develop to master. Ideally, the merge from develop to master is fast-forward and the two contain the same commits, with master just trailing behind.
On 1/10/19 6:58 PM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
That is, develop is not a place for experimentation (or, ironically stated, develop is not for development). The squashing, if needed, happens on the merge from the experimental feature branch into develop, not on the merge from develop to master. Ideally, the merge from develop to master is fast-forward and the two contain the same commits, with master just trailing behind.
Hmm - but then when the CI fails on develop and a few more tweaks are necessary basically to deal with compiler/ci vagaries, this cruft then ends up on the master history. Also, then shouldn't master just be just a tag into the the last passing develop branch? I do think it would be useful for someone to "codify" these practices because a lot of don't know (and don't really want to know) and don't really care which practices to follow and would be happy to follow whatever someone who spends time with this stuff has concluded would be the best way. just my 2 cents. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, 11 Jan 2019 at 06:05, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 1/10/19 6:58 PM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
That is, develop is not a place for experimentation (or, ironically stated, develop is not for development). The squashing, if needed, happens on the merge from the experimental feature branch into develop, not on the merge from develop to master. Ideally, the merge from develop to master is fast-forward and the two contain the same commits, with master just trailing behind.
Hmm - but then when the CI fails on develop and a few more tweaks are necessary basically to deal with compiler/ci vagaries, this cruft then ends up on the master history.
There is possibility that infrastructure stuff is different in master vs develop, or minor maintenance of build scripts and tweaks go into develop directly. Such exception to Peter's is not uncommon. It's also possible tweaks go into master only But, since Boost does GitFlow, master is never merged into develop, so it should not be a problem for merges in the reverse direction.
Also, then shouldn't master just be just a tag into the the last passing develop branch?
Are you suggesting departure from GitFlow, or has it already happened?
I do think it would be useful for someone to "codify" these practices because a lot of don't know (and don't really want to know) and don't really care which practices to follow and would be happy to follow whatever someone who spends time with this stuff has concluded would be the best way.
I'd be happy to learn myself too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Fri, 11 Jan 2019 at 03:59, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Robert Ramey wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
That is, develop is not a place for experimentation (or, ironically stated, develop is not for development). The squashing, if needed, happens on the merge from the experimental feature branch into develop, not on the merge from develop to master.
I second and follow the same as Peter's while working on Boost.GIL. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 1/11/19 5:58 AM, Peter Dimov via Boost wrote:
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
That is, develop is not a place for experimentation (or, ironically stated, develop is not for development).
What's the purpose of develop then?
On Fri, 11 Jan 2019 at 11:26, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 1/11/19 5:58 AM, Peter Dimov via Boost wrote:
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
That is, develop is not a place for experimentation (or, ironically stated, develop is not for development).
What's the purpose of develop then?
Production staging? A safety net master is always shippable? But I've also wondered about it, hence my question in response to Robert's post. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
What's the purpose of develop then? Production staging? A safety net master is always shippable?
But I've also wondered about it, hence my question in response to Robert's post.
Exactly that. You usually have CI on 3 levels (possibly with increasing complexity on e.g. compilers tested): 1. PRs 2. develop 3. master Why is the 2nd stage required? Assume you have 2 MRs. The first introduces a new file using some existing functionality. The 2nd changes/removes/renames that existing functionality and all references. Both MRs pass CI and are merged. But now your develop is broken as the update from the 2nd was not applied to the feature in the 1st. Another commit (possibly directly to develop) fixes this after which CI passes. Now you can put this into master.
On 1/11/19 8:47 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
What's the purpose of develop then?
Integration testing.
Integration testing is done on master. Multiple libraries may differ between develop and master when you merge to master, so the testing on develop does not guarantee success in master. One thing is true, though. Develop allows other libraries to be tested with your change. Again, this doesn't guarantee success when the change is merged to master, but at least it gives an opportunity to detect problems earlier.
On 1/11/19 10:25 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
One thing is true, though. Develop allows other libraries to be tested with your change.
Precisely.
It also allows provisional changes in other libraries to affect one's own test results. This can lead to huge wastes of time trying to find the source of bugs that were "secretly" inserted into your library. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
On 1/11/19 10:25 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
One thing is true, though. Develop allows other libraries to be tested with your change.
Precisely.
It also allows provisional changes in other libraries to affect one's own test results. This can lead to huge wastes of time trying to find the source of bugs that were "secretly" inserted into your library.
If you don't do integration testing on develop, you'll do it on master, at a higher cost, when the "provisional" changes land there. Or, as they say, if you don't have a test server, you do have a test server, you just call it "production".
On 1/11/19 11:12 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
On 1/11/19 10:25 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
One thing is true, though. Develop allows other libraries to be tested >> with your change.
Precisely.
It also allows provisional changes in other libraries to affect one's own test results. This can lead to huge wastes of time trying to find the source of bugs that were "secretly" inserted into your library.
If you don't do integration testing on develop, you'll do it on master, at a higher cost, when the "provisional" changes land there.
Or, as they say, if you don't have a test server, you do have a test server, you just call it "production".
It's not that I'm against doing the "integration testing" at all. I recognize that this needs to be done from time to time - presumably soon before a new release is shipped. But if the "next" version of each library is tested against the master, integration testing errors should almost never occur. But of course theory depends on assumptions that are not strictly true (e.g. stable interfaces) so "integration testing" is still required. The problem is that when it is done continuously, transitory errors can be tripped in dependent libraries. Since the dependent libraries presume that the other libraries being used are correct, they don't really check for errors - they just fail to perform correctly and soldier on. The requires that the working library be investigated to discover the source of a flaw which originates outside the library one is working on and testing. It can take a huge amount of time to track this down. Worse, the offending library isn't notified of the problem the author is created and time is lost. Robert Ramey
Robert Ramey wrote:
It's not that I'm against doing the "integration testing" at all. I recognize that this needs to be done from time to time - presumably soon before a new release is shipped.
No, it needs to be done continuously. Allow me to repeat for context:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
The point of not using develop for provisional changes is exactly to enable other libraries to use it without breaking all the time. Provisional changes, under this model, go into feature branches. Once they are no longer provisional, they go into develop. Under this model of development, develop is as stable as master would have been otherwise. Of course, if one of your dependent libraries does not use this model, and "provisions" directly into develop, it makes things harder for you, because develop breaks all the time. And conversely, if you "provision" directly into develop, you make things harder for your dependencies.
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
My guideline is:
- work that has passed local tests goes into a feature branch - feature branches that have passed CI go into develop - develop that has not broken anything goes into master
I find this too conservative myself. For me: - develop branch is where development happens. - master branch gets merges from develop branch when all tests pass on all supported platforms. - Particularly well tested moments in time of master branch get tagged with version numbers or some other form of named stamp. Feature branches off of develop occur only for "what if" experiments which may be discarded, and for pull requests as usually people submit PRs against master branch and I have to rebase them to develop. Niall
On Thu, Jan 10, 2019 at 9:20 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
Robert Ramey
Any merge from master into develop should be empty (i.e. nothing to do). This ensures you didn't miss anything in the past through a bad procedure. (for example someone checking into master directly, which I've seen) Any merge from develop into master should always be a fast-forward. If you squash commits when going from develop to master, you cannot prove that develop is missing anything from master because you cannot merge master into develop. I had to do this and fix up the missing/conflicts on all the CMT repositories. I'd also recommend if you have more branches lying around than develop and master that you consider removing them unless they are for active team development of a feature. Otherwise you should be using a fork and using your own travis and appveyor accounts to prep your changes so that you do not consume Boost CI resources. My recommendation is that your commits to develop are considered project history and they do not get rewritten by rebase or squash into master, and certainly never by a force push. Pull requests run the same CI as a push does, so you should be able to get CI stable on your PR before you rebase your PR into develop. Then you can always merge (fast-forward) develop into master. I don't see any benefit in consolidating all the changes in master to one commit. You can accumulate all the changes using git by comparing the tags between releases. Further nobody who consumes boost from a release sees any of this stuff anyway. If you want to fix your branches, do this: 1. git clone your-repo 2. git checkout -t origin/develop 3. git merge master If you have any commits in master not in develop, this will pick them up. 4. git push 5. git checkout master 6. git merge develop This merge should be a fast-forward because of what you did in 3. What you proposed by squashing commits into master would cause us to have to force push a new consolidated commit into master during the release cycle, which would rewrite history, which is bad for everyone. - Jim
On 1/11/19 5:20 AM, Robert Ramey via Boost wrote:
I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated.
I think, squashing commits when merging to master is a terrible idea because it makes tracking differences between develop and master difficult and tracking history of changes by master log virtually impossible. I don't see why would anyone would want to do that. There is also a possible issue with commit authorship, which is presumably lost when you squash commits. Depending on how you deal with commit messages, these might be lost as well. Of course, the decision is yours, so you can do that if you want to. But I hope you're not meaning to force-push to develop the squashed commits because that would affect everyone using develop of your library. In particular, it would break git pull. Also, it breaks superproject, which now references non-existant commits from your git repo. IMO, force-pushing to develop and master should be locked for all libraries.
On Fri, 11 Jan 2019 at 14:30, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
IMO, force-pushing to develop and master should be locked for all libraries.
+1 If there is a team of maintainers, granting right to merge into master just one of them is also worth to consider. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 1/11/19 5:29 AM, Andrey Semashev via Boost wrote:
I think, squashing commits when merging to master is a terrible idea because it makes tracking differences between develop and master difficult
When I look at the history of develop and master I expect to see: on develop - all the history which led me to each release. on master - the history of the releases - and nothing else. As it is now - I see in the master the detailed history with a lot small changes - same as the develop. It makes me reluctant to check small changes to develop knowing that all this transient unintrestesing and confusing history will be forever with us. I guess it comes down to this. If the master is just a copy of develop then what's the point of it? It's just one more thing to get out sync. Having a master only seems to make sense if it's a different thing - ie a history of releases. Robert Ramey
On 1/11/19 5:30 PM, Robert Ramey via Boost wrote:
On 1/11/19 5:29 AM, Andrey Semashev via Boost wrote:
I think, squashing commits when merging to master is a terrible idea because it makes tracking differences between develop and master difficult
When I look at the history of develop and master I expect to see:
on develop - all the history which led me to each release.
on master - the history of the releases - and nothing else.
As it is now - I see in the master the detailed history with a lot small changes - same as the develop. It makes me reluctant to check small changes to develop knowing that all this transient unintrestesing and confusing history will be forever with us.
What do you mean by the history of releases? You can already see the list of releases by git tag. If you want to see the changes between releases then the git log or git diff between the two tags gives you that - in addition to keeping the particular commits that are referenced by PRs, issues and what not with their respective authors and comments. Having git log show only one commit per release, saying something like "Boost X.Y release" is not helpful, IMO. 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.
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? Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
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
On 1/11/19 8:28 PM, James E. King III via Boost wrote:
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,
I was responding having what Robert proposed in mind, i.e. assuming that master has squashed commits.
participants (10)
-
Alexander Grund -
Andrey Semashev -
Deniz Bahadir -
James E. King III -
Mateusz Loskot -
Niall Douglas -
Paul A. Bristow -
Peter Dimov -
Robert Ramey -
Stefan Seefeld