On 29.03.2017 16:36, Jord van der Elst wrote: > There were many commits, but all those commits don't necessarily make it > into a client build. That completely depends on what's in David's build > directory. If he just added those two commits, it's just those two commits > that made it.
That is not how git works. It's not a matter of what was in David's build directory it's a matter of which commit was used to checkout the build directory (more technically: to which commit did HEAD point to when the build was done). So what we need to know is the exact SHA1 that was used to build the Client/Manager that was bundled into the installer. That SHA1 can then be used to build the exact same versions for Linux and Mac. It probably is f640f89b while it should have been 7436252a (btw: a good example for a non-atomic commit) but there is only one person who knows that. > e.g. I'll add all the "client" commits that were made since June 06 2016 > (which is when 7.6.33 was released, so count from that day onwards) to this > email. They may all be commits, but they don't all have to be in 7.7.2. And > that's why I said earlier, that I think we won't know until David says what > he added. If the Client/Manager was built from one of the commits above then every commit in master is part of the history of this version. Since the 7.6 series diverged from master when the client_release/7/7.6 branch was created there are commits that are in both branches (master and the release branch), only in the release branch and that are only in master because they were never cherry-picked into the release branch. That makes it hard to say what changed between 7.6.33 and 7.7.2. Using the release date is also not a good idea as this does not show the commits in master that ar enot part of the release branch. You need to know the SHA1 of this build (6f6c8b7eb). So you now need to look at the commit history between the two SHA1. There are a total of 3675 commits between those two SHA1 and github only shows the 250 most recent: https://github.com/BOINC/boinc/compare/client_release/7.6/7.6.33...7436252a (if you see the unicorn just reload) You can achieve the same locally via "git log --pretty=format:"%h : %s" --graph client_release/7.6/7.6.33...7436252a" which will give you the exact difference between those two SHA1 going back until the divergence of the 7.6 release branch. There are supposed to be a lot of duplicates in there (differing only by SHA1) as some contributors didn't cherry-pick but created new commits when they added changes to master and the release branch. Restricting to commits that have "client" in the commit title is also wrong as there is no commit discipline in BOINC (aka. no atomic commits) and you can have client changes embedded in other commits (where the message doesn't state that). You would need to at least include commit titles with "lib" too and that would probably still miss a lot of changes. You would need to restrict to commits that changed files in client/, clientgui/ and lib/. I think it's a good idea to follow Richards suggestion to treat 7.7.2 as a private build and just forget that it exists (as we forget that there is no version 7.7.0 and version 7.7.1). Then come up with a proper plan to go forward with 7.7/7.8 that follows todays best practice. Regards Christian _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
