Changing master to main

OHDSI · Jan 21, 2022 · a83fb22 · a83fb22
1 parent a67d77d
commit a83fb22
Show file tree

Hide file tree

Showing 20 changed files with 140 additions and 108 deletions.
diff --git a/.github/workflows/R_CMD_check_Hades.yaml b/.github/workflows/R_CMD_check_Hades.yaml
@@ -113,7 +113,7 @@ jobs:
           path: check
 
       - name: Upload source package
-        if: success() && runner.os == 'macOS' && github.event_name != 'pull_request' && github.ref == 'refs/heads/master'
+        if: success() && runner.os == 'macOS' && github.event_name != 'pull_request' && github.ref == 'refs/heads/main'
         uses: actions/upload-artifact@v2
         with:
           name: package_tarball
@@ -127,7 +127,7 @@ jobs:
     env:
       GH_TOKEN: ${{ secrets.GH_TOKEN }}
 
-    if: ${{ github.event_name != 'pull_request' && github.ref == 'refs/heads/master' }}
+    if: ${{ github.event_name != 'pull_request' && github.ref == 'refs/heads/main' }}
 
     steps:
 

diff --git a/Rmd/community.Rmd b/Rmd/community.Rmd
@@ -19,7 +19,7 @@ The HADES workgroup has regular meetings. Meetings are open to all, and will be
 ```{block2, type='rounded'}
 ### Next HADES meeting
 
-Date: **December 16, 2021**
+Date: **February 18, 2022**
 
 Time (DST where appropriate):
 
@@ -35,6 +35,10 @@ URL: [Join Microsoft Teams Meeting](https://teams.microsoft.com/l/meetup-join/19
 
 ## Prior meetings
 
+### 2022
+
+- January 20: *2022 objectives and key results*. See recordings in Teams
+
 ### 2021
 
 - November 18: *Study packages, Hydra, renv, and Docker*. [Notes](meetings/Hades18Nov2021.docx) and [slides](meetings/HadesNovember2021.pptx)

diff --git a/Rmd/contribute.Rmd b/Rmd/contribute.Rmd
@@ -18,5 +18,5 @@ If you're a bit more experienced with HADES and are looking to improve your open
 
 # Write unit tests
 
-An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are [several unit tests](https://github.com/OHDSI/CohortMethod/blob/master/tests/testthat/test-psFunctions.R#L5) that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!
+An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are [several unit tests](https://github.com/OHDSI/CohortMethod/blob/main/tests/testthat/test-psFunctions.R#L5) that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!
 
diff --git a/Rmd/developerGuidelines.Rmd b/Rmd/developerGuidelines.Rmd
@@ -47,7 +47,7 @@ All of these should be generated when releasing a new version, as discussed in t
 
 ### README.md
 
-In addition, the README.md file forms the main page of the package repo. This page has a standard structure, as for example can be seen [here](https://github.com/OHDSI/FeatureExtraction/blob/master/README.md).
+In addition, the README.md file forms the main page of the package repo. This page has a standard structure, as for example can be seen [here](https://github.com/OHDSI/FeatureExtraction/blob/main/README.md).
 
 ## extras folder
 
@@ -93,7 +93,7 @@ We use `codecov` in combination with the `covr` package to measure which lines o
 
 On the OHDSI Jenkins server there are 3 databases that can be accessed from within a unit test, for the 3 main platforms (SQL Server, Oracle, PostgreSQL). To access the databases locally, you'll need to specify several environmental variables. These environmental variables should also be available when running tests using Github Actions.
 
-Some example code in the DatabaseConnector package can be found [here](https://github.com/OHDSI/DatabaseConnector/blob/master/tests/testthat/test-connection.R).
+Some example code in the DatabaseConnector package can be found [here](https://github.com/OHDSI/DatabaseConnector/blob/main/tests/testthat/test-connection.R).
 
 
 # Coding guidelines

diff --git a/Rmd/packageStatuses.Rmd b/Rmd/packageStatuses.Rmd
diff --git a/Rmd/packages.Rmd b/Rmd/packages.Rmd
@@ -30,6 +30,7 @@ Below are the packages included in HADES. For each package a link is provided wi
 <ul id="pkg">
 <li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/Andromeda">Andromeda</a></h4>Storing very large data objects on a local drive, while still making it possible to manipulate the data in an efficient manner.</br><a href="https://ohdsi.github.io/Andromeda">Learn more...</a></li>
 <li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/BigKnn">BigKnn</a></h4>A large scale k-nearest neighbor classifier using the Lucene search engine.</br><a href="https://ohdsi.github.io/BigKnn">Learn more...</a></li>
+<li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/Capr">Capr</a></h4>Develop and manipulate complex cohort definitions in R</br><a href="https://ohdsi.github.io/Capr">Learn more...</a></li>
 <li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/CirceR">CirceR</a></h4>An R wrapper for Circe, a library for creating cohort definitions, expressing them as JSON, SQL, or Markdown.</br><a href="https://ohdsi.github.io/CirceR">Learn more...</a></li>
 <li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/CohortGenerator">CohortGenerator</a></h4>Instantiating cohorts in a database based on a set of cohort definitions.</br><a href="https://ohdsi.github.io/CohortGenerator">Learn more...</a></li>
 <li><h4><i class="fas  fa-cube "></i> <a href="https://ohdsi.github.io/Cyclops">Cyclops</a></h4>Highly efficient implementation of regularized logistic, Poisson and Cox regression.</br><a href="https://ohdsi.github.io/Cyclops">Learn more...</a></li>

diff --git a/Rmd/releaseProcess.Rmd b/Rmd/releaseProcess.Rmd
@@ -9,9 +9,9 @@ output:
 
 All development should be done in the `develop` branch of the package GithHub repository. The aim should be to have a workable version in `develop` branch, so **make sure your package passes R CMD check locally before pushing to the `develop` branch**.
 
-# The master branch
+# The main branch
 
-The head of the `master` branch should be the latest released version of the package. No changes should be directly pushed to the `master` branch.
+The head of the `main` branch should be the latest released version of the package. No changes should be directly pushed to the `main` branch.
 
 # Continuous integration
 
@@ -53,7 +53,7 @@ Only the package maintainer may create a new release. The release should be prep
 
 	- Update the package version number in the DESCRIPTION file.
 	- Update the date in the DESCRIPTION file.
-	- Ensure the Remotes section in the DESCRIPTION file only references the master branch of repos.
+	- Ensure the Remotes section in the DESCRIPTION file only references the main branch of repos.
 	- Ensure *no* Git tag or GitHub release with the new version number already exist. Delete them if they do.
 
 
@@ -70,9 +70,9 @@ Only the package maintainer may create a new release. The release should be prep
 
 4. For those packages that go into CRAN: Check the package using `devtools::check_win_devel()` and `devtools::check_rhub()`, and submit to CRAN using `devtools::release()`.
 
-5. Once all these steps are completed and commited to the `develop` branch, the package can be released by merging `develop` into `master`. 
+5. Once all these steps are completed and commited to the `develop` branch, the package can be released by merging `develop` into `main`. 
 
-	Pushing changes to the `master` branch where the version number in the DESCRIPTION file is higher than the current one will trigger the automated release process. If the package passes R check, the following steps are automatically performed:
+	Pushing changes to the `main` branch where the version number in the DESCRIPTION file is higher than the current one will trigger the automated release process. If the package passes R check, the following steps are automatically performed:
 
 	- A new release and tag are created in the GitHub repo with the version number.
 

diff --git a/Rmd/renv.Rmd b/Rmd/renv.Rmd
@@ -56,7 +56,7 @@ At the core of `renv` is the 'renv.lock' file that specifies all required packag
 			"RemoteHost" : "api.github.com",
 			"RemoteRepo" : "Covid19EstimationHydroxychloroquine",
 			"RemoteUsername" : "ohdsi-studies",
-			"RemoteRef" : "master"
+			"RemoteRef" : "main"
 		}
   }
 }
@@ -106,7 +106,7 @@ Many HADES packages need to be installed from GitHub rather than CRAN. See the '
 - **RemoteHost**: Should always be "api.github.com".
 - **RemoteRepo**: The name of the HADES package repo, for example "FeatureExtraction".
 - **RemoteUsername**: This should always be "ohdsi" for HADES packages.
-- **RemoteRef**: The GitHub reference. For HADES packages it is recommended to use the git tag of the version, for example "v3.1.1" for version 3.1.1. (In HADES, all package releases are automatically tagged with a "v" prefix and then the version number). This could also be set to the name of a branch (e.g. "master"), but the contents of a branch tend to change over time, so this will break reproducibility. 
+- **RemoteRef**: The GitHub reference. For HADES packages it is recommended to use the git tag of the version, for example "v3.1.1" for version 3.1.1. (In HADES, all package releases are automatically tagged with a "v" prefix and then the version number). This could also be set to the name of a branch (e.g. "main"), but the contents of a branch tend to change over time, so this will break reproducibility. 
 
 ### OHDSI Study packages
 
@@ -119,15 +119,15 @@ Many HADES packages need to be installed from GitHub rather than CRAN. See the '
 			"RemoteHost" : "api.github.com",
 			"RemoteRepo" : "Covid19EstimationHydroxychloroquine",
 			"RemoteUsername" : "ohdsi-studies",
-			"RemoteRef" : "master"
+			"RemoteRef" : "main"
 		}
 ```
 
 As discussed later in this document, sometimes we would like to include an OHDSI study package in the lock file as well. These entries are identical in terms of `Source`, `RemoteType`, and `RemoteHost` to those for HADES GitHub packages, but differ in these fields:
 
 - **RemoteRepo**: The name of the OHDSI study package repo, for example "Covid19EstimationHydroxychloroquine".
 - **RemoteUsername**: This should always be "ohdsi-studies" for OHDSI study packages.
-- **RemoteRef**: The GitHub reference. This is often "master", for the master branch, but can also refer to the name of a git tag, or the hash of a specific git commit.
+- **RemoteRef**: The GitHub reference. This is often "main", for the main branch, but can also refer to the name of a git tag, or the hash of a specific git commit.
 
 
 # Creating a renv lock file

diff --git a/Rmd/support.Rmd b/Rmd/support.Rmd
@@ -18,6 +18,8 @@ Bug reports should be files using the issue tracker of the misbehaving package:
 
 - [BigKnn issue tracker](https://github.com/OHDSI/BigKnn/issues)
 
+- [Capr issue tracker](https://github.com/OHDSI/Capr/issues)
+
 - [CirceR issue tracker](https://github.com/OHDSI/CirceR/issues)
 
 - [CohortDiagnostics issue tracker](https://github.com/OHDSI/CohortDiagnostics/issues)

diff --git a/docs/community.html b/docs/community.html
@@ -442,7 +442,7 @@ <h1>Meetings</h1>
 
 <div id="next-hades-meeting" class="section level3 rounded">
 <h3>Next HADES meeting</h3>
-<p>Date: <strong>December 16, 2021</strong></p>
+<p>Date: <strong>February 18, 2022</strong></p>
 <p>Time (DST where appropriate):</p>
 <ul>
 <li><strong>6pm Central European time</strong></li>
@@ -456,6 +456,12 @@ <h3>Next HADES meeting</h3>
 <div id="prior-meetings" class="section level2">
 <h2>Prior meetings</h2>
 <div id="section" class="section level3">
+<h3>2022</h3>
+<ul>
+<li>January 20: <em>2022 objectives and key results</em>. See recordings in Teams</li>
+</ul>
+</div>
+<div id="section-1" class="section level3">
 <h3>2021</h3>
 <ul>
 <li><p>November 18: <em>Study packages, Hydra, renv, and Docker</em>. <a href="meetings/Hades18Nov2021.docx">Notes</a> and <a href="meetings/HadesNovember2021.pptx">slides</a></p></li>
@@ -469,7 +475,7 @@ <h3>2021</h3>
 <li><p>January 21: <em>Study package guidelines, system requirements, GitHub Actions, Objectives and key results</em>. <a href="meetings/Hades21Jan2021.docx">Notes</a>.</p></li>
 </ul>
 </div>
-<div id="section-1" class="section level3">
+<div id="section-2" class="section level3">
 <h3>2020</h3>
 <ul>
 <li><p>December 17: <em>GitHub Actions, System Requirements, CDMv6, Communication</em>. <a href="meetings/Hades17Dec2020.docx">Notes</a>.</p></li>

diff --git a/docs/contribute.html b/docs/contribute.html
@@ -442,7 +442,7 @@ <h1>Write help files</h1>
 </div>
 <div id="write-unit-tests" class="section level1">
 <h1>Write unit tests</h1>
-<p>An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are <a href="https://github.com/OHDSI/CohortMethod/blob/master/tests/testthat/test-psFunctions.R#L5">several unit tests</a> that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!</p>
+<p>An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are <a href="https://github.com/OHDSI/CohortMethod/blob/main/tests/testthat/test-psFunctions.R#L5">several unit tests</a> that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!</p>
 </div>
 
 

diff --git a/docs/developerGuidelines.html b/docs/developerGuidelines.html
@@ -462,7 +462,7 @@ <h2>Documentation</h2>
 <p>All of these should be generated when releasing a new version, as discussed in the <a href="releaseProcess.html">Release Process</a> section.</p>
 <div id="readme.md" class="section level3">
 <h3>README.md</h3>
-<p>In addition, the README.md file forms the main page of the package repo. This page has a standard structure, as for example can be seen <a href="https://github.com/OHDSI/FeatureExtraction/blob/master/README.md">here</a>.</p>
+<p>In addition, the README.md file forms the main page of the package repo. This page has a standard structure, as for example can be seen <a href="https://github.com/OHDSI/FeatureExtraction/blob/main/README.md">here</a>.</p>
 </div>
 </div>
 <div id="extras-folder" class="section level2">
@@ -500,7 +500,7 @@ <h3>Code coverage</h3>
 <div id="testing-functions-requiring-database-access" class="section level3">
 <h3>Testing functions requiring database access</h3>
 <p>On the OHDSI Jenkins server there are 3 databases that can be accessed from within a unit test, for the 3 main platforms (SQL Server, Oracle, PostgreSQL). To access the databases locally, you’ll need to specify several environmental variables. These environmental variables should also be available when running tests using Github Actions.</p>
-<p>Some example code in the DatabaseConnector package can be found <a href="https://github.com/OHDSI/DatabaseConnector/blob/master/tests/testthat/test-connection.R">here</a>.</p>
+<p>Some example code in the DatabaseConnector package can be found <a href="https://github.com/OHDSI/DatabaseConnector/blob/main/tests/testthat/test-connection.R">here</a>.</p>
 </div>
 </div>
 </div>
Original file line number	Diff line number	Diff line change
Expand Up		@@ -18,5 +18,5 @@ If you're a bit more experienced with HADES and are looking to improve your open

		# Write unit tests

		An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are [several unit tests](https://github.com/OHDSI/CohortMethod/blob/master/tests/testthat/test-psFunctions.R#L5) that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!
		An important part of validating the methods in the library is unit testing. A unit test is a small program that tests a specific function in the library. For example, there are [several unit tests](https://github.com/OHDSI/CohortMethod/blob/main/tests/testthat/test-psFunctions.R#L5) that make sure the propensity score matching works correctly. We can never have enough unit tests, and writing unit tests is an excellent way to learn how HADES packages work under the hood. Make sure you read through the Develops section first!