Robert Ramey schreef op 23-1-2015 om 7:47:
As a reminder - I maintain that the merge from develop into master is a trivial operation. If anyone is finding this not to be the case, they are not doing right.
My proposition is that merging from development to master is trivial operation. If it isn't for you, then you're doing something wrong. The difficulties or peculiarities of any particular library are irrelevant to my view and my argument.
LOL - one might say it's special. But merging one's current develop branch into the master is a trivial operation. If it's not then he's doing wrong.
Or possibly when he says "merging the develop branch" into the "master" he's referring to other stuff like debugging code while it's in develop or who know what else. This other stuff has nothing to do with merging the develop branch into the master branch. LOL - we're not communicating. merging develop into master should require absolutely no coding. At the end of the operation for the library in question the code in the master should be bit for bit identical to code in the develop branch - that is all that the merge does. (could be a slight simplification if multiple authors are working on the same library and the authors are conflicting - but would be an extremely rare case here so I'm ignoring it).
Apparently you are quite convinced that merging to master is trivial. It is *not*. First you have to convince yourself the regression matrix on develop is green, or the non-green cells are explainable. Then you have to be sure that all the recent commits, merges and pull requests are reflected in the regression matrix. That might take a couple of days, so preferable people have to stop with all changes on develop, a few days before merging to master. Requires planning and communication. * (see below) Then you have to be sure your master is up-to-date, pull, update sub-modules Then you have to build and unit-test your to-be-merged code (on develop) where all other libraries are master-branch: it might break because of changes in other libraries. That can take several minutes up to more than an hour (depending on the size of the library and unit test coverage). Hopefully all unit-tests pass! If not, you really have to find the cause, and take action (update renamed headerfiles, read documentation/updates, read the boost mailing list, communicate to the list (if the problem is in another library) or your team (if the problem is in your library or in the changed usage of the other library). You cannot merge as long as there are failures. Maybe it is not your fault that it fails! Maybe there is a dependancy on updates of another library, or on Boost.Test. Then that library should be merged to master first. You then have to wait until that is merged (or remove the dependancy). Also compile the documentation! Boost.Build or some other doc-tools might have been updated on master. Ideally you do this on at least two platforms or compilers. Assume all tests pass. Then you can merge to master! This part is indeed trivial. Is there anything redundant in this list? Be sure to check the regression matrix on master the few days after merge! *Additionally preparing for a release (master), all release-notes have to be up-to-date, all documentation has to be up-to-date and reflect the last changes in the library, etc. Of course this should be done on-the-fly, while developing, but sometimes those things are a bit behind. I put this apart because it is not really part of the merge process and ideally should not be necessary. This is why I prefer to merge only once per release. Regards, Barend