[CRAN Release]: 0.1.12

### Blocked by

#### PRs
- [x] PR 1

#### Issues
- [ ] Issue 1

### Pre-release

- [x] Make sure you adhere to CRAN submission policy:
* https://cran.r-project.org/web/packages/submission_checklist.html
* https://cran.r-project.org/web/packages/policies.html.
- [x] Make sure that high priority bugs (label "priority" + "bug") have been resolved before going into the release.
- [x] Review old/hanging PRs before going into the release (Optional).
- [x] Revisit R-package's lifecycle badges (Optional).
- [x] Make sure that all upstream dependencies of this package that need to be submitted to CRAN were accepted before going into release activities.
- [x] Make sure integration tests are green 2-3 days before the release. Look carefully through logs (check for warnings and notes).
- [x] Decide what gets merged in before starting release activities.

### Release

#### Prepare the release
- [ ] Create a new release candidate branch
`git checkout -b release-candidate-vX.Y.Z`
- [x] Update NEWS.md file: make sure it reflects a holistic summary of what has changed in the package.
- [x] Remove the additional fields (`Remotes`) from the DESCRIPTION file where applicable.
- [x] Make sure that the minimum dependency versions are updated in the DESCRIPTION file for the package and its reverse dependencies (Optional).
- [x] Increase versioned dependency on {package name} to >=X.Y.Z (Optional).
- [x] Commit your changes and create the PR on GitHub (add "[skip vbump]" in the PR title). Add all updates, commit, and push changes:
```r
# Make the necessary modifications to your files
# Stage the changes
git add
# Commit the changes
git commit -m "[skip vbump] "
git push origin release-candidate-vX.Y.Z`
```

#### Test the release
- [x] Execute the manual tests on Shiny apps that are deployed on various hosting providers (Posit connect and shinyapps.io) - track the results in GitHub issue (Applicable only for frameworks that use Shiny).
- [x] Monitor integration tests, if integration fails, create priority issues on the board.
- [x] Execute UAT tests (Optional).

#### CRAN submission
- [x] Tag the update(s) as a release candidate vX.Y.Z-rc (e.g. v0.5.3-rc1) on the release candidate branch (release-candidate-vX.Y.Z).
```r
# Create rc tag for submission for internal validation
git tag vX.Y.Z-rc
git push origin vX.Y.Z-rc
```
- [x] Build the package locally using the command:`R CMD build .` which will generate a .tar.gz file necessary for the CRAN submission.
- [ ] Submit the package to https://win-builder.r-project.org/upload.aspx for testing, for more details please see "Building and checking R source packages for Windows": https://win-builder.r-project.org/.
- [ ] Once tested, send the package that was built in the previous steps to CRAN via this form: https://cran.r-project.org/submit.html.
- [ ] Address CRAN feedback, tag the package vX.Y.Z-rc(n+1) and repeat the submission to CRAN whenever necessary.
- [ ] Get the package accepted and published on CRAN.

#### Tag the release
- [ ] If the additional fields were removed, add them back in a separate PR, and then merge the PR back to main (add "[skip vbump]" in the PR title). If nothing was removed just merge the PR you created in the "Prepare the release" section to 'main'. Note the commit hash of the merged commit. **Note:** additional commits might be added to the `main` branch by a bot or an automation - we do **NOT** want to tag this commit.

##### Make sure of the following before continuing
- [ ] CI checks are passing in GH before releasing the package.
- [ ] Shiny apps are deployable and there are no errors/warnings (Applicable only for frameworks that use Shiny).

- [ ] Create a git tag with the final version set to vX.Y.Z on the main branch. In order to do this:
1. Checkout the commit hash.
`git checkout `
2. Tag the hash with the release version (vX.Y.Z).
`git tag vX.Y.Z`
3. Push the tag to make the final release.
`git push origin vX.Y.Z`
- [ ] Update downstream package dependencies to (>=X.Y.Z) in {package name}.
**Note:** Once the release tag is created, the package is automatically published to internal repositories.

### Post-release

- [ ] Ensure that CRAN checks are passing for the package.
- [ ] Make sure that the package is published to internal repositories.
- [ ] Make sure internal documentation is up to date.
- [ ] Review and update installation instructions for the package wherever needed (Optional).
- [ ] Announce the release on ________.

### Decision tree

Click [here](https://github.com/insightsengineering/.github/blob/main/.github/ISSUE_TEMPLATE/RELEASE_DECISION_TREE.md) to see the release decision tree.