All, As you may know, one of the things that has been "not great" about the OpenCPI github repo was that for a while the master branch had no relationship with the current or latest released software.  While in general anyone using a github repo for sources should be specific about what they are checking out (a tag or a non-default branch), some people expect the "default" download/clone to be usable without checking anything out.   But until now OpenCPI did not meet this expectation. So one of our "punch list" items for cleaning up the OpenCPI repo was to make the master branch work in the way that many other repos work and stop being "different". I.e. make the master branch always "deployable" by having it always be the latest stable usable release. I bring this up now because we have made that change this afternoon, and there might some fallout. Of course we were not expecting anyone to directly use the master branch in any case since it was not really a stable version and was not tagged. Thus the current master branch on github is now the same as release 1.4 and it will soon be the same as release 1.5 If you have git clones that happen to be on the (old) master branch with any work in them you need to take some measures. ***Do not do "git pull"***! If you are actually working in the old "master" branch for some reason (*git status* tells you that you are on the master branch), you should do: *git fetch* (which will inform your local repo about a new remote branch called "old_master", and the re-targeted remote branch "master") *git branch -u origin/old_master* (tell your local "master" branch to follow the remote old_master branch) *git branch -m master old_master* (rename your local "master" branch to be the local "old_master" associated with the remote "old_master") Do not do "git pull" until you have done the above steps!  These steps keep your local repo workable in the branch where it was (now called old_master). Hopefully this won't cause anyone (if there is anyone in this state) much trouble.  If anyone has further suggestions about "coping" with this change, please chime in. Going forward, any work that might result in a pull request should be based on a branch from a release tag (i.e. typical practice). We know that the git history is still not ideal for contributors, but this step brings us a bit closer to "best/expected practice" in this regard. Thanks. Jim