In that case, the workflow document linked by David earlier - https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement - contains totally unnecessary extra work steps:
* Clone branch: clone https://github.com/boinc/boinc.git into new dir w/ version num * Right-click on dir; switch to new branch * set version numbers in * /: configure.ac, version.h, version.h.in, version.log * in version.h, version.h.in: comment out pre-release with C syntax * android: TODO; Oliver: textual representation, numerical value (increment) in 7.6, it's 146, so use 147 * commit * create tag client_release/7.8/7.8.0 * git push, check "include tags" The only reasons I can see for creating a new directory are: To create clean build folders for the development tools to work in To create an offsite archival backup in case of disaster and both of those should be done *after* the version number updates and tagging have taken place. On Friday, 4 August 2017, 10:54, Charlie Fenton <charl...@ssl.berkeley.edu> wrote: Hi Oliver, Perhaps I'm not understanding what you meant by "contains", but if I create a new branch named "newbranch" from an existing branch named "oldbranch", then any commits made to oldbranch after that are not included in a build I make using newbranch unless I specifically port them over, such as by cherry picking them from oldbranch into newbranch or by merging one branch into the other. Is that not so? I agree that your local repository always does contain all commits made to all branches as of the last time you synced with the remote repository, so you can "check out" any branch or tag you wish. As I understand it, checking out a branch or tag simply "hides" from your development tools anything that is not considered part of that branch or tag, while "revealing" to your developer tools everything that is considered part of the branch or tag. This allows us to perform a build at any time from exactly the same source files as were originally used to build the version represented by the tag. And it allows us to build from a feature branch without including subsequent changes made outside that branch, which can be useful while developing a feature. Since the client_release/7/7.8 branch was created from master and was then immediately tagged as client_release/7/7.8.0, Richard is correct that, as a result of the way the branch was created, all the Drupal source code up to that time became available in the branch and under that tag, along with everything else in master at that point. I believe that is what he meant by "included". Cheers, --Charlie On Aug 4, 2017, at 12:45 AM, Oliver Bock <oliver.b...@aei.mpg.de> wrote: > On 03/08/17 17:03 , Richard Haselgrove wrote: >> it also means that the whole of the Drupal source code was included in the >> v7.8.0 'client' tag. > > Just to avoid potential confusion: we're not using SVN anymore. A git > branch always "contains" the whole repo, not some copy of specific parts > of it. > > Best, > Oliver > _______________________________________________ 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. _______________________________________________ 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.
